After listening to the #PineTalk episode recently, I have had a long hard think about a particula…

After listening to the #PineTalk episode recently, I have had a long hard think about a particular subject that was brought up: “Do you really want a Linux Phone”

At the risk of alienating some of my followers on the fedi, here are my thoughts:

  • We need to educate non-linux users, rather than getting annoyed at them for “not knowing” or “not doing the research”
  • Developer and contributor ego needs to be left at the door. It’s unproductive.
  • We need a universal unified design language, so that developers of apps can meet those minimum requirements, otherwise we end up with a ton of half complete, incompatible or non-conforming junk
  • The name or ethos of a project or app, is less important than its discovery, security and usability
  • Putting links; credits and project information in the “About” of an app, is enough. Confusing people with strange or non-generic app names, just makes your project or app seem pretentious, not unique
  • Stability and efficiency are far more important than extraneous and non-core functions and features
  • User experience needs to be paramount, not an afterthought
  • We should work to make new users loyal and knowledgeable long term users, and we cant do that by discouraging them
  • I dislike the “figure it out for yourself” attitude. Not everyone has the reasoning or research skills that we take for granted, and we should be helping these people learn

I have a little bit of an idea on how we can resolve some of these things:

  1. We need a standard Icon Set that is immediately recognizable, so that no matter what distro you are using, you can find what you’re looking for quickly. Custom colors etc, is not the issue, it’s the recognizably that is important. Humans are visual beings. We look for things that are familiar.
  2. Projects need to stop being so self interested in their own walled gardens. Apps are a part of a bigger ecosystem, they all need to communicate better, and stop the pretentious ego driven need to be different. One application is NOT always better than another, and unless you have massive brand recognition (on the scale of something like Firefox), then the only applications that should have extremely unique names and Icons are transient 3rd party apps and games. I know this is an ugly word, but conformity breeds familiarity. If you have a familiar interface; app name and icon, your application will be much more recognizable, and therefore receive much more use as a result.
  3. There are only two core features of the #PinePhone (or #LinuxPhone) that absolutely MUST function, which are simply make and receive phone calls and send and receive SMS messages. Without these, all other projects are moot. If the PinePhone cannot receive phone calls or SMS messages in a reliable way, then the phone is dead in the water. Making these the highest priority for all LinuxPhone projects, should be an obvious step.
  4. Projects need to work towards “feature complete”, not “almost complete”. Having an app that technically works, but requires editing of scripts to customize it, is absolutely ridiculous. No average end user is going to say “Sure, let me open the terminal, learn how it functions; learn how to navigate the file system using the cli; learn how to use nano or vim; learn the syntax of the language used for the config file; learn which variables need to be edited and how; then save, close and restart the app.
  5. Forums; Wiki’s and Bug reports turn off prospective new users. We need to find an alternative that provides a more personal (and arguably more agreeable and centralized) method to how we look after our users. Telling people to “Search the forums”; “Fix it yourself” or “Have you searched the bug reports”, is an absolutely horrible way to deal with users. So you don’t like dealing with the same questions over and over, I get it, I do. But don’t punish new users because you’re frustrated.

On point #5 – I was thinking about this even more in depth. If some enterprising group were to create a general “Support Team” that lend their services to multiple projects, that could work as an intermediary between the end users and the dev teams, this could (at least partially) solve the issue. Dev teams only get properly logged bug reports without the hassle of dealing with repetitive questions (allowing them to focus on their work), and end users get immediate answers without the need to try and translate “developer speak”, and dealing with pissed off programmers.

What do you think? Would this help solve the support problem? Should I attempt to create such a group?

#Rant #Ethos #Pine64

@PINE64 @talkpine @linmob @purism


AnotherKiwiGuy is a lazy ass and is OFFLINE