Yes, pushing a new version every day is bound to create negative associations. It's not unique to the Android app update model though, it works much the same way in NetBeans and Firefox, except updates are typically much less frequent (unless you added a bunch of "private" update centers). The fact is that it's quite invasive to have 10+ updates a day to handle manually.
On Android that is about to change though, the moment a user can just mark an application as "automatically update to latest" or click "Update all" that should mitigate the problem somewhat. After all, most users do not need to know an application was updated, let alone see a changelog. What many applications seem to do is show their own changelog Intent the first time the application is run after a major release - but never for a maintenance/security release. Google is likely still investigating these issues and how to provide the best user experience. A custom policy for how often to check for updates would go a long way I think, currently it's pretty dumb, i.e. right after an app was manually updates the daily update service pops up to remind the user that there is an update for that app. On Jun 1, 2:57 pm, Fabrizio Giudici <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Many of us agree on the goodness of agile methods that lead to / > allows to have frequent releases. Since when we work as consultants > for a customer we have a good relationship with him/her (*), we can > explain him what's happening (in fact, sharing the perspective and > values is fundamental withing agile methods). > > But what about end customers? We can't and we shouldn't evangelize > them (they want to use the damn'd thing, not to learn about > techonology), so they'll have their own perception. At the moment, I'm > having a release per week for my Android application. I've still to > learn how to do automated UI tests, but the rest of the code has a > very good coverage; I'm manually filling the gaps, and since the > application is simple I can afford to do it manually. In the end, I > feel confident - when I have full UI tests I'll feel even more confident. > > But yesterday I happened to read the blog of an italian journalist, > about the iPad application developed by one of the most spread italian > newspaper. He said "the app is poor and they published an update right > the day after the public release" - the tone was a critical one, as to > point out defects of the first release. So, suddenly, I realized that > maybe customers might see frequent releases... as a bad sign! What > should one do? Keep frequent releases internally and publish only once > in a while? > > PS Of course, this is related to the bad way the Android Market is > done. There's no official place for a changelog, if you put it in the > description field (which is short) it will consume room for a decent > description of the application; and even if you publish the change log > to your website, you have to find a way to have it read by the end > customers... > > (*) If you don't have at least a decent relationship with your > customer, the project will fail even when done with Agile^3, Java 8 > with multi-dimensional closures, etc... > > - -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > java.net/blog/fabriziogiudici -www.tidalwave.it/people > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAkwFA6cACgkQeDweFqgUGxff3wCfXQL0Dw7IFPpaLsXG1bN8pX/p > /fgAnAsXKDrrYxsTBrHjCR32cnoX+mMX > =tjSV > -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
