When it's a matter of principles, it can be hard to let go of certain
ideas. Yet at the end of the day, this comes down to how well does
Ubuntu as a phone platform compete with Android and IOS. When mobile
phones first came into fashion (remember the 90's folks?), battery life
on handsets was upwards of a week. I remember laughing at the first
'smart' phones, and their battery life of a couple days (if you were lucky).
Then smart-phones got more powerful, and users wanted more. 1 day of
battery life became the 'norm'. People no longer minded charging their
device each day, providing their 'apps' worked as they should - instant
notification, multi-tasking, working in the background. Even IOS
eventually capitulated - I still remember back when doughnut was a thing
on Android, how Apple maintained their phones weren't powerful enough
for multi-tasking, when the HTC Magic (remember /that/ handset?) was
able to manage just fine with lower specs. It was a design decision
Apple made for - wait for it - battery life.
Perhaps if Apple and Google had started implementing more background
services apps could plug into, a better format could have been found.
But that didn't happen. In the race to market, the easiest way for
developers to engage with their devices won out. This might not have
been the best way, but its what currently is expected in the market.
'Bucking the trend' is important - it can even bring great success. But
to do so faces an uphill battle all the way. Something needs to be
offered that's a better result than the status quo. Uber, Flow Hives,
Ebay - recent history is full of inspired examples. This - at a minimum
- needs to meet what's currently on offer, or throw the model away and
start something better. Success for Ubuntu on phones will come from
consumer adoption - consumers that are used to their apps just
'working'. People that won't understand - nor care - why they can't
check emails while jogging. Why they need to keep an app 'in focus' in
order for basic functionality to work. Why their Facebook app is only
the web interface with a fancy bottom navigation button - why there's no
messenger. Why developers don't port more of their apps - the fact that
many developers won't be interested in working around Ubuntu's platform
restrictions won't register with consumers - the fact the app isn't
there will be enough.
As an end-user and consumer, technical descriptions of multi-tasking are
next to useless. If an app won't work unless it's in the foreground,
it's not multi-tasking. As a tech-enthusiast that uses Ubuntu in
everything I do, I'm willing to find work-arounds. Most people won't do
that. So the question becomes who Ubuntu is targeting? Everyday
consumers who expect apps to work in the background (thus allowing the
user to multi-task in their day), or enthusiasts who are willing to
embrace a rougher experience?
If battery life has ceased to become the biggest selling point in the
market, why is Ubuntu pushing this as the most important issue? Why is
ease of use and usability being sacrificed for battery life? Is this a
matter of principles, or is there an overarching design decision that
will push Ubuntu as a platform ahead of the rest? There are lots of
examples on this mailing list of better solutions - at the end of the
day, what's a better experience for consumers? Rather than expend so
much effort working around the principles for Ubuntu's current app
restrictions, wouldn't a better way forward be to optimize the system
processes for battery-life, then have an easily accessible menu where
end-users can see which app is draining their battery? This could then
become the first port of call for users complaining about battery life.
Apps in the store would reflect this in ratings - would you rate an app
highly that drains your battery?
And so a last question - rather than spending so much time and effort
writing background processes to make apps on Ubuntu appear that they are
working as expected on other systems, wouldn't an easier way be to
remove the current app restrictions with regards to background
processes, and implement a solution where users are able to see which
app is draining their battery?
Mitchell
On 03/10/15 07:03, John Johansen wrote:
On 10/02/2015 08:32 AM, Thomas Voß wrote:
On Fri, Oct 2, 2015 at 5:04 PM, sturmflut <sturmf...@lieberbiber.de> wrote:
Hey Thomas,
On 02.10.2015 16:44, Thomas Voß wrote:
Let's make sure that we are untangling the lifecycle policy discussion
we are having here from the
discussion of enabling apps to prevent the device from going to deep
sleep. The latter one can be solved and
both you and me have been talking about the solution. With that,
keeping the tracking app in the foreground is perfectly fine.
Screen goes off, devices stays operational, problem solved :)
Nope. That forces the user to keep the tracking app in the foreground.
That means the user can not go about using their phone in the regular
way if they want the tracking app to function.
Receive an sms, or email. Switch to reply, now you are forced to
return to the tracking app. Instead of just continuing on your way
especially if you are expecting another response soon.
Out walking, and take or make a call while continuing to walk, to
bad your tracking app doesn't support that. Forcing the user to
deal with this is not user friendly especially when the competition
does not have such restrictions.
Wait.
So we would then have three cases?
Sure, this topic is orthogonal to the lifecycle discussion, though.
Not really, it is a design decision that forces a certain tying of the
two, as your response clearly shows. The lifecycle affects what and
how an application can do some things. It forces certain design choices
and atm even forces certain user behaviors. The most common use cases
can eventually be covered by background services but it will never
cover all use cases.
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
