Some personal feedback about Vanilla
businessdad
MVP
Today I was tidying up my projects, and, when it was time of "Vanilla" directory, I got surprised of how many of them I got up and running in a relatively short time. I prepared a dependency diagram and I noticed that, thanks to the flexibility provided by the framework, I seamlessly built a "suite" of components, without having necessarily designed it as such.
To be honest, when I first used Vanilla, I was a bit disappointed to see that so many of the features I needed were missing, but I also got surprised of how easy it was to add them. The answer to anything missing was not just DIY, but YCDIY (You Can DIY). I wish I could say the same for other monster frameworks, where adding a feature is a DIY-If You Can (har har har).
Vanilla definitely has its issues (lack of documentation is at the top of the list; fortunately, the Community compensates for that), but it's usually easy to fix them, or to work around them. At the end of the day, it's by far one of the easiest frameworks I have ever worked with.
In short: well done to the Vanilla Team and to the Community. There's still room for improvement, but, so far, you're doing great!
Comments
Thank you so much for this. We hear you about the documentation too.
@Todd is there anything in specific I could help with in regards to documentation and the wiki?
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
You know it might just be good to have a conversation about documentation on the forum before getting into that. We've actually had some talks about documentation at Vanilla HQ over the past few weeks and it has even resulted in me hacking some of the zend reflection classes to get together some decent docs. But before I get ahead of myself here...
We think we want to design good documentation which isn't straight forward. Getting the ux right is really important to me. If you look around the web most of the great documentation is for apis, not frameworks.
The thing I want right now is a short walkthrough on "the way to code Vanilla" and then a big indexed reference. That's where I am right now.
Can I make a suggestion.
We have some whizzkids on here, so why not create a dynamic page.
Like a flow chart.
User selects from drop down an issue, then another select box appears with choices... etc etc, then the result polls the search and displays results below.
There was an error rendering this rich post.
What type of users do you predict would be reading the documentation the most: developers or general users?
Add Pages to Vanilla with the Basic Pages app
@Shadowdare, we are talking about developer documentation here.
As much as I like the spirit of vanillawiki, I think the http://vanillaforums.org documentation should be solely focused on the precise documentation, of the framework, in a more formal style, but clear and concise.
It shouldn't concern general development advice, and tidbits (which is more for blogging), though showing how the framework works in a practical sense is good.
As it is an ongoing process you need some system in place.
I like the topological approach generally, but "revelation" style intros are also good to get into a framework.
It is interesting that MVC framework documentations often start with describing the dispatcher and controller aspects first, the request end if you like. Where as pluf which is a MVT (Model, View, Template) framework, where views in this are roughly analogous to Controllers, and Templates to views in MVC, when they did they documentation they explained it backwards, the response end first. They started with the Templates then explained the Views then Models. Then after they explained the Dispatch loop.
I guess this is a first sight mentality, which a lot of people who have never use or understood a MVC or MVT would struggle with, doing it backwards, takes them from the most familiar to the least, rather than the other way round. And they will understand why things are done the way they are, better.
In pluf they explain
In Vanilla/Garden
You can explain additional things like modules, and helpers, after the get the gist. Go through common thing that developers are going to want to do.
From there you can explain the core framework. You can explain how applications are put together, the plug-ability, and theme-ability.
Then after I would just have a formal straightforward documentation.
What I would get away from is list of content of seemingly unconnected documents.
grep is your friend.
seconded.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
I'd like to echo businessdad's sentiments. Every week boxes are ticked and items marked "Complete" on my project roadmap thanks to Vanilla's "everything is possible and within reach - don't panic!" nature. Thanks to Todd and the guys for putting this in people's hands.
This is so true. I was going through the burn down charts of my Vanilla projects and it's amazing how quickly the get "turned to ashes". My latest two projects, the Post Scheduler and the Badges plugins, despite being fairly complex, have taken me dramatically less than my Cron plugin, which was the first one I coded, when Vanilla meant just "ice cream flavour" to me.
Once I found useful patterns, I was able to reuse them in new projects (despite varying context), improve them, and update previous projects seamlessly. This level of consistency, which, theoretically, should be expected from any framework, is quite rare.
My shop | About Me