| Thread Previous • Date Previous • Date Next • Thread Next |
something like: 1) possibilities hardware wise 2) target audience 3) goals (ranked in importance) 4) current situation software wise, when looked at 35) things that need to change/updated in ranking of importance (should be easy after doing 1-4) 6) methods of implementation (so you need to revisit 1-5 here every now and then to see if the method is feasable. Btw, I'm just brainstorming a tiny little bit, don't nail me down cuz of this list only. I'm sure it could be improved on when done in detail.)
7) start/continue working on the software side 8) test9) back to 4 and see if you got what you wanted to get, if yes, great. if not, go through 4-9 again.
etc.I'm not very knowledgeable when it comes to the technical side of computers (sorry for that), but everything just seems like some sort of unorganized mess right now, which is regrettable because this phone seems a) interesting b) a source of potential and c) fun to play around with.
And in all honesty, if you apply the above to the current situation then the situation does not look good. But maybe I'm seeing things wrong. I'm just a beginner.
Again, this is not an attack or such, but just....a few things could be a bit more organized imo as we don't have unlimited resources available like those Apples, Googles and Microsofts are having. There is the need for some more efficiency.
Have a great day, Ashwin On 2015年10月03日 07:29, Mitchell Reese wrote:
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<sturmflut@xxxxxxxxxxxxxx> 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.
| Thread Previous • Date Previous • Date Next • Thread Next |
