Should web applications offer versions?
Something that I love about desktop software is the choice to upgrade. When a new version of an application is released I’m usually notified the next time I launch it. If the developer was kind enough, I’ll even have some release notes to peruse so that I can read about what was updated, what has been fixed, etc. Then I can choose if I want to update the application or not.
You don’t have this choice with web applications. When an update is rolled out for any of the web applications you use, sure you might be notified of the update and even be told what has changed since your last visit, but you are not offered the choice to use this updated version because it is forced on you.
But progression is good, right? The new version is surely better than the last.
We have good examples of desktop applications gone awry between versions. In recent memory we have the upgrade from iMovie ‘06 to iMovie ‘08 in the new iLife ‘08 suite of applications from Apple. The move from iMovie ‘06 to ‘08 was less an ‘upgrade’ and more ‘a whole new application’. For some, this came as an un-welcomed surprise. There are some things that iMovie ‘06 was able to do that the new iMovie ‘08 can not. This isn’t to say that iMovie ‘08 isn’t a great application worthy of purchasing, just that as an “upgrade” it can be jarring when features and interface familiarity drop off the face-of-the-earth.
The best thing about the iMovie situation is that people can choose to upgrade. I know people that have both iMovie ‘06 and iLife ‘08 installed. Choice is good.
What if you woke up this morning and Gmail looked like Hotmail? The feature set, the interface, everything - was exactly like Hotmail. You’d probably think that the Gmail development team was pulling a fast one on you and you’d probably check your calendar to see if it was April 1st. But surely the Gmail team is smarter than this. They know that making huge changes to an application can alienate past users, so they just won’t do something like that. Or will they? Or have they?
Perhaps I’m ignorant of a good example of this happening in web applications. Maybe there is a service out there that, when making major upgrades, does somehow offer the user the choice to use the most up-to-date version. I’m not sure. But supposing this is something to think about how could it be done? Is it feasible? Or am I just too picky?
November 5th, 2007 at 12:36 pm
Is there any downside to forcing the users to adjust to new interfaces and feature sets on web applications? Any intelligent application provider will think twice before completely revamping their application in ways like you exemplified.
It’s a matter of feasibility and providing “what’s best” for your users.
Firstly, at least for social applications, to provide different code bases and database configurations for different types of users would likely not even be possible in the world of traditional DBMS’s, let alone what the hassle would be to run to different uniquely optimized code bases.
Secondly, does it really happen that often that web applications change so much that they alter how you fundamentally use the web service? Your two examples would be such examples, but people don’t do that. And if they did (in the case of Microsoft Office 2007 or the re-vamping of Google Reader), it would be at the disgression of the application provider to decide what they deem a best choice for the user. People will upgrade to new versions of software no matter how different they become because thats how we are used to reacting to new versions of things. If users of web applications were provided the option to upgrade in these extreme situations they would likely choice the upgrade path not because they think that’s best but because it’s what they think of as “default” in their mind. It wouldn’t make sense to impose such a question on the majority of users because likely the majority of the users that were afraid to upgrade would simply be because of laziness and fear.
November 8th, 2007 at 5:30 pm
Zach makes some very good points. I think another aspect you would have to look at is the age of the web application/service. If it’s something that’s very young and just getting started, the first steps in the upgrade process are to improve the existing functionality and killing bugs from real-world use. I don’t know anyone that would choose to avoid seeing the benefits of that.
On the other hand, when it’s a mature site I can see the point you’re asking about. What I think happens, if a web app/service is going to change as dramatically as something like iMovie (which really should have been given a different name in ‘08), is the branching off into a separate site. It’s so easy to EOL a website by just stopping any further development. When an idea changes so drastically, I seem to recall that most developers will simply let the site languish — or sell it — and move on to another site/service. Then it’s the choice of the visitor/member/user if they want to join the new site or stick with the current one, just like you’re suggesting.
Why don’t you check the viability with Viddler? Is this something you guys think you could do?
November 11th, 2007 at 7:53 am
Zach: Excellent points. I realize the hassle of offering two separate versions of, anything. Just ask Brent Simmons with NetNewsWire and NetNewsWire Lite. While he has a place in his heart for both applications - keeping both of them up-to-date is a full time challenge. I think one reason he wrote about this recently is because he is going a little against the grain with Lite and probably receives criticism, or maybe just general questions, about why he maintains two separate code bases.*
Something I hope is that all application developers will want to be as “nice” as you’re stating.
Mike: I definitely agree that most users will want to take advantage of bug fixes, security patches, and the like. The biggest worry isn’t about getting new features or the application getting refinement - the biggest worry is when features disappear (like the example I gave with iMovie).
About Viddler: This is exactly why I wrote this post. We have a fairly unique position that a portion of our “application” or service is seen by people that never visit the site. The player. Our player is under constant development. Without checking my guess is that the current build that is being seen right now is just over 400+. We’re constantly refining the underpinnings, and we sometimes adjust the interface as well. So far, at least not to my knowledge, we haven’t lost any features. But I worry about the day that we do, and so this question popped into my head!
Perhaps we’ll do some experimentation with our awesome beta team on Viddler, who tests new things for us, and I will report back here once we see the results of that.
November 11th, 2007 at 7:54 am
Hah! I had a “footnote” in that last comment - so here it is.
* Brent has mentioned, in the video from An Evening at the Adler, that he uses Frameworks to keep both NetNewsWire and NetNewsWire Lite much easier to manage.
November 28th, 2007 at 9:18 pm
This is a great concept.
Most developers (and all should) use version control.
It’s especially easier if they are strong in GIT(http://git.or.cz/), which allows for easy merging of branches. In theory, this could mean that you could allow for different version of the same app, but as you find bugs and exploits and patch them up, you can fix multiple different versions.
Of course, the overhead is huge for the developers.