The upcoming b2evolution v4 release is intimidating on several counts:
- It includes more new features than any other single release before...
- It includes code from more different contributors than ever before...
- and last but not least... I haven't made a release in 6 months, so I'm pretty scared about screwing something up...
This leads me to runs extra tests even for the alpha version, just to make sure it's working all nice and clean, especially the upgrade process, which is pretty intense this time. I mean that on a code level. It's all automatic, so for the user it should be transparent.
At this point I have tested b2evolution v4.0.0-alpha on the following hosts: InMotion, HostMonster, BlueHost, FastDomain, FatCow, HostGator, HostPapa, LunarPages, ANhosting, HostIcan, JustHost, GreenGeeks and IX. I found a few small issues along the way, got them fixed, and so far it's looking good.
I also upgraded my personal blog, and now this blog right here... it seems to be working fine but I'm tempted to keep it under observation for a couple more days... unless you guys want me to rush it out as fast as I can now?
Update July 18th: The b2evolution.net site now also runs on b2evo v4. We are finding small bugs, nothing major, but we'll try to fix the most itching ones in the next couple of days... and then release.
Some like it strong. Some like it light. Some like it with milk. Some like it hot. Some like it chilled… There is no single right way to serve coffee.
It’s pretty much the same when it comes to software, blog software for that matter.
Some want more this. Some want more that. Some want less this. Some what a different kind of that. There is no single right way to design blog software.
Every feature can be debated as long as you want, but at the end of the day there’s always gonna be 4 groups:
- People who are for it;
- People who are against it;
- People who want it, but in a different way;
- People who don’t care…
So, in the end, you either do nothing or you make a decision that’s going to please one group, not please another, irritate a third one and mostly go unnoticed by a fourth one.
Breadcrumbs is a feature I've been wanting to implement for quite a long time. In b2evo 4, I started adding them to the admin interface...
I realized one of the reasons we failed to implement them properly before is because we tried to tie them to the navigation. In theory it makes complete sense that the breadcrumb path follows the navigation. In practice however, it doesn't! One of the reasons for this is that b2evo's admin has 2 main dimensions of navigation:
- Navigate through features, sub-features, etc.
- Navigate from one blog to the next
I believe that the breadcrumb path doesn't make sense until it integrates the second dimension into the first at some point... which has to be an arbitrary point, but nonetheless... The result is what you can see on the first image above. What do you think?
I think it works pretty well, but I can take no credit: I just followed the instructions from Steve Krug's Don't Make Me Think by the letter ;) (page 78)
I must admit though, there's one area that isn't crystal clear in the book and I can't quite make my mind up:
“The only constant is change.”
Everything changes. And when it comes to technology, everything changes rapidly. b2evolution is no exception. Humour me while I’m even temped to say “it’s in its genes to evolve” ;)
On the other side of the equation, we have the user: the human. And one fairly consistant trait among humans is resistance to change..
I am a victim of this myself. I tend to reject everything that breaks my habits. It often takes me months before I get used to something new, I mean: to something different from what I was used to. But once I’m used to it, I finally tend to come around and realize the new thing gives me a better experience overall.
(Btw, I believe that working on lowering your own resistance to change is key to not getting old & grumpy too fast, but that’s another subject I can’t really talk about, especially until I’ve made some significative progress myself ;)
For example, I am currently typing this on one of those Apple “flat keyboards". I hated them at first! I even bought spares of the previous “white keyboard” model while I still could. Because I thought I’d never, ever, want to use those stupid flat keyboards! Now I’m using one and I’m happy about it… It turns out that once you get used to the different feel of the keys, they are actually more relaxing to type on…
Anyways, back to b2evolution: it is always difficult when you release a new version with new features. Some of these features invariably get into the way of some habits you may have developed over the years with the previous version(s). People will inavriably resist to change. Sometimes loudly. Sometimes aggressively. Sometimes constructively too… the last group always save the day ;)
The users who most constructively break down their psychology are the most valuable to improving user experience. They may come up with hints, suggestions or sometimes even complete solutions that will make the transition easier – that “lessen the resistance” if you wanna look the beast into the eyes ;) We (the developers) generally try to react to those suggestions, but I have to admit the timing is not always right. Sometimes it takes months before the “easier” version comes out… :/
That is why I no longer insist that everyone upgrades to newer versions as soon as they are stable. Once stability has been taken care of, usability sometimes takes a little longer to adjust… (bear with us, we too are only humans ;)
A few years ago I once said sth along: "oh yeah, we could make the core super small & lightweight and have almost everything work as a plugin".
Well, that was a very long time ago... in between I have realized this:
- The plugin architecture works well for some features and is just a horrible hack for some others. Making it clean would require such a complex plugin architecture that it would actually defeat the purpose of simplicity we had in the first place.
- The plugin approach is very much like a "linux package" approach: incredibly appealing to geeks. I can understand that. It's also equally incredibly impossible to grasp for my father (let alone my mother). In other words: the majority of users faint when they have to think about "installing", "compatibility", "dependencies", let alone "conflicts".
- Adding more features/modules/files to b2evolution actually does not make it slower. Most of these files are never loaded into memory except for the exact moment when you use them. Splitting an app into multiple files is actually the simplest possible plugin system you can imagine.
- I switched to the Mac... And this is something I would never have understood before: a system made of parts assembled from different sources will never match the experience of a coherent system where everything has been designed and tested to work together (I'm not saying our testing process is perfect, just that it's better than untested assemblies of parts from various sources). It's not like the Mac won't let you install 3rd party software. It's just that it provides you with a basic set of functionality that makes it possible for most beginners to NOT EVEN THINK about the system for several months/years. IT JUST WORKS for everything they need, until significantly later in their learning curve.
This is why, when I repeatedly read/see/hear users trying to do this or that with b2evolution, I now tend to consider whether or not that feature would make sense in the core/distribution/as a bundled plugin.
b2evolution will never have all the features everyone may need. And for every feature it has, there will always be a plugin with more advanced features. But my ambition is that most users starting with b2evolution won't NEED TO THINK in order to do what they want to do until several months down the road.
Right now, too many run into a missing piece before they even start blogging.
Inspiration: Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug.
In my mind, plugins are particularly useful in these situations:
- Features that are useful only to a minority of users;
- Features that are experimental;
- Interfaces to proprietary systems (like twitter for example);
- Giving options when there are competing solutions (like wysiwyg editors).