Hi, Arjan van de Ven wrote: > On 6/23/2010 8:15 AM, Dave Neary wrote: >> Here's a few examples that come to mind: >> >> * Video player - wants to give best experience possible when on A/C, so >> goes with HD, high frame rate - but when on battery, reduces video >> quality& frame rate to use less energy > > but your phone and tablet almost always are only used on battery. So > basically you now have degraded behavior > all the time the user is using the device. sounds like a really bad plan > to me.
There's the bandwidth issue, which is separate - and there are codecs that can adaptively change their bandwidth usage. But yeah, I think that there are apps where it's appropriate to have a lesser user experience for someone who's not on A/C. > the difference between 5 minutes and 30 minutes is not power visible to > be honest; this would be a "how am I connected" tradeoff not a power one. > And .. half an hour on all phones all the time? you're kidding ;) Without getting into the details... the principle stands. And again, I see the bandwidth issue as only one parameter. The key is "do less". Just out of interest, do you see half an hour as too far apart, or too close together? I'm having trouble figuring out. > i can go on and on, but... with devices being almost always on battery, > and your examples very visibly and annoyingly degrading the experience... > (and often NOT being about AC/Battery.... but about where the device is > at that point in time) Meh. I guess we have different ideas about what "degrading" means. I think the user experience you expect does change if you're on the move. Of course, if you're thinking about a laptop, you might consider some of the ideas here annoying. But I definitely think that the use-case when you have a phone in your pocket or on a charger is different than a netbook. Perhaps you're falling into "All the world's a netbook" thinking a little? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
