Results of the Requirements Survey for a KDE-wide Chat Solution

A week ago, I wrote my previous blog post about a survey I had set up, to figure out how important each of the requirements we had collected for a common IM / chat solution for KDE is for us.

All in all, 132 people followed my request to participate in the survey, and answered the 108 questions in it. Thank you all for taking the time!

This post presents the result of the analysis of your answers.

Survey Participant Experience

Normally whenever I conduct a survey, before releasing it onto participants, I collect feedback from a bunch of testers to see if there is anything confusing or annoying in it. It’s just standard practice.

I should have known that if I ever decide not do it, it would backfire. Normally I design surveys from scratch or reuse ones I or a colleague has made. This time, I followed a recommendation from a fellow KDE usability consultant to use kanosurvey.com, since it is a pre-made survey tool with an established underlying model. You just have to enter the features you want to ask about, the tool does the rest. I thought “Hey, these surveys are conducted all the time in all kinds of contexts with all kinds of people, always with the same questions, so it should be safe to just apply it here as well, right?”

Wrong. As soon as I asked people to participate, I got lots of comments about how difficult it was to fill out the survey, how unsure people were which answers to choose.

This is how a question in the survey looks:

Kano survey question.png

The biggest problem participants had was whether to choose “I like it this way” or “I expect it this way” as their answer to the first question. They tried to mentally bring all answer options into a logical order, but were unsure whether “like” or “expect” was stronger.

Now the problem is: There is no strict logical order to the answer options. The reason for that is that the Kano model does not simply split features into “want” and “don’t want”. What it aims to do is categorize features into mandatory (expected) ones, exciting (surprising) ones, those which are “the more, the better” (called “linear” or “one-dimensional”), those about which people just don’t care (“indifferent”), and those which they actually dislike (“negative”), the specific terms used differ between people applying it.

A feature which users expect to be present, and dislike to be absent, is a must-be, whereas one which they like to be present but don’t care if it’s absent is an exciting feature. Neither of them is necessarily “stronger”: Must-be features are mandatory, but if you want people to choose your product, you better make sure you also have some features which cause excitement.

Participants expressed their concern that they might have distorted the results if they were unsure whether to choose “expect” or “like” if something felt like a must-have for them. The good news is: As long as they chose “dislike” on the absence question, it doesn’t really matter that much which of the two they chose on the presence question. We’ll make sure that both the must-be and the linear features will be present in the solution we choose, because we don’t want people to miss anything that they care about.

On the other hand, I also got positive feedback from participants who liked the idea of looking at each feature from two different angles.

Still, a survey which makes participants confused or even angry is not a good survey. I won’t use kanosurvey.com again, at leats not for this target audience.

The Results

With that out of the way, let’s get to the actual results. What kanosurvey.com spits out after calculating the individual answers is, for each requirement, how many individual answers fell into each of six categories: The ones mentioned above, plus “Questionable” (which I’ve relabeled to “Misunderstanding” in the table below). Questionable means that the combination of answers for a participant are unexpected from the Kano model perspective and therefore indicate that the participant misunderstood either the description of the requirement or the question. We’ve had a few of those in the survey, but luckily never more than one participant per requirement. This shows that despite the subjective confusion, the answers which the participants gave were still almost entirely in line with the what the model expects, and therefore usable.

Now the next question is: What to do with this? In general market(ing) research, what people do is calculate which product configuration would give them the best chance in the market through a combination of meeting people’s expectations and getting them excited.

We’re not doing regular market research, however. The solution we choose should not exclude people, so we can’t just say “As long as enough people will like our solution, it’s fine”. Therefore, I chose a custom approach to the analysis:

  • If a feature is mandatory or linear for more participants than an exciter, and less than half (66) of the participants are indifferent or negative, I considered it a Must-have. There is no way around this feature if the solution is supposed to be accepted by the community.
  • If a feature is an exciter for equally or more participants than mandatory and linear combined, and less than half of the participants are indifferent or negative, I considered it an Attractor. If we want our community to welcome a solution as an improvement, it better had that feature.
  • If at least half of the participants were indifferent about a feature, but it’s still mandatory or linear for at least 20 participants (and negative for less than 20), I categorized it as “Inclusion”. That means although the majority doesn’t care, not having this feature would exclude a significant number of contributors from using the solution. That would only be okay if we offer those people an alternative (e.g. a bridge to a solution that does have that feature).
  • If more than half of the participants were indifferent about a feature, less than 20 considered it mandatory or linear and less than 20 considered it negative, I categorized a feature as “Nice-to-heave”. That means exactly that: It’s nice if it’s there (and may attract some people), but the majority just doesn’t care and few people consider it a must, so if it’s not there, it’s no big deal.
  • If more than 20 participants were negative about a feature, but it was overall positive for more than 20, I considered it “problematic”. That means some people would like a solution to have this feature, but a significant number of people would actually dislike it because of that. That means if we choose a solution which has that feature, there better be a way for users to turn it off.
  • If more participants disliked a feature than those on the three positive categories together, I labeled it “avoid”, meaning that the presence of such a feature would do more harm than good.

Here is the list of requirements sorted by the categories:

Table with results

Unfortunately I was not able to turn the results into a proper HTML table in a way that worked for me, so the current presentation is not screen-reader-compatible. People who need screen readers or who want to do more things with the numbers can download the spreadsheet from which the image above was exported from share.kde.org.

The Next Step

So, now that we have the prioritized (or rather categorized) requirements, the task is to find a solution that:

  • Has all he must-haves
  • Ideally has all the attractors
  • Does not exclude those who need the inclusion features
  • Maybe also has some of the nice-to-haves
  • Does not have the Problematic or Avoid features at all, or has an off-switch for them if it has them

Time to get searchin’!

Advertisements
Tagged with: , ,
Posted in KDE

The Quest for a Common Chat/IM Solution

Konqi between chat solutionsA Free/ Open Source Software community usually uses several means of communication: Among them are email, forums, code review and bug tracking systems, nowadays also video chat systems, but one of the central communication channels is usually real-time text communication, also known as instant messaging or chat.

Traditionally, IRC has been the cornerstone of chat in the FOSS world, as it is open, easy for everyone to join (no account needed) and not in control of any single organization. IRC still does what it was designed for perfectly well, but while it is still basically the same as it was 20 years ago, the world of chat and instant messaging around it has evolved significantly in the meantime: Instant messaging services such as WhatsApp or Telegram (or KakaoTalk, WeChat or Line in Asia) are used by pretty much everyone (and their parents, literally) and systems such as Slack are dominating company communication, and those systems have shaped how people expect a chat system to look and behave.

While this does not really bother long-term members of FOSS communities such as KDE, who know IRC inside and out and feel perfectly comfortable with it, we have noticed that for many new and young potential contributors, IRC feels like a “relic of the past”, due to how it is presented and the features it offers.

Therefore, Telegram has become the standard communication tool for the designers in the VDG, and WikiToLearn uses rocket.chat and Telegram as well. This works okay for the time being, as users in Telegram groups can communicate with users in corresponding IRC channels via bridges. However, it still feels disconnected, because the bridges limit functionalities like mentioning users or sharing images, and setting up a bridge requires manual effort for each group/channel, while people often create ad hoc Telegram groups for specific topics. It’s also difficult for people to find relevant Telegram groups unless a link to them is put manually on the community wiki.

The biggest problem with Telegram is, however, that while its client code is open-source and they offer an API for developing additional clients, the server side is fully controlled by a single company, which means our communication on Telegram is fully dependent on whatever that company decides to do.

To fix this situation, three weeks ago Jonathan Riddel proposed on the KDE Community mailing list that we switch from our mix of solutions to rocket.chat for all of KDE. This proposal sparked a very long and occasionally heated debate with each side arguing why their solution is better. At some point I realized that we’ll hardly ever reach a conclusion if we don’t even know what exactly our requirements are for a common chat solution. To fix this, I started an Etherpad to collect requirements.

While doing that, we realized that there was quite some disagreement about which features or properties were “must-haves” and which were “nice-to-haves”. That’s when Heiko Tietze suggested that it could make sense to use the Kano model to figure out which features are indeed must-have for the majority of our community, which are not needed but would make people want to use a solution, which ones the majority doesn’t actually care about and which might even annoy people. He also suggested a tool called Kano survey which allows to capture this information easily in an online survey.

So I set up a survey about “Requirements for a primary Chat/IM solution for KDE” to prioritize our identified requirements. Now if you would like to contribute your opinion on the importance of the different requirements because you regularly communicate with KDE on our current IRC, Telegram or rocket.chat channels, please fill in the survey here until Thursday, August 31st.

Tagged with: , ,
Posted in KDE

My Plans for Akademy / QtCon

going-to-akademy-2016

It’s finally that time of the year again which many KDE contributors have been looking forward to: The time when we all get together at Akademy, to meet our KDE friends in person, give and listen to talks and make plans for world domination!

This year is special because Akademy will be part of QtCon, a joint conference with Qt, FSFE, VideoLAN and KDAB, which means even greater opportunities to learn something new, reach an audience beyond KDE, and deepen our alliances!

This year, I’ll give three quite different talks:

The first one, on Saturday, is titled “Quo Vadis, KDE? – A FOSS Community’s Journey toward its Vision and Mission“. There I will talk, together with Lydia Pintscher, about how the desire to find a direction for KDE lead to the KDE Evolve initiative, which lead to the KDE Vision and Mission initiatives, and beyond.

The second one, on Sunday, titled “Meet Kirigami UI – How KDE’s new framework can help to create multi-platform mobile and convergent applications” will be a more product-oriented / technical one. Here, Marco Martin and I present our convergent application framework, Kirigami. I will talk about some design background, whereas Marco will go into technical detail and explain how to set up a project that uses Kirigami.

The third talk I’ll be giving (also Sunday), this time together with Jens Reuterberg, is again more on a “meta level”: Under the title “Movements and Products” we will talk about two different mindsets with which contribution to a Free Software community can be approached: A product-focused mindset or a movement-focused mindset. The two are not mutually exclusive, and in fact we’d recommend adopting some of both for a community like KDE to succeed as a movement that creates products.

If you can’t be at QtCon or can’t make it to the talks: I assume the pages linked above will have recordings to download at some point.

Giving talks is not the only thing I do at Akademy / QtCon, of course. There are also all kinds of BoF sessions to attend: On Monday, I’m planning to be at the Plasma BoF (and especially at the Kirigami-focused part in the afternoon, of course), as well as the “Appstream metadata on software releases” BoF (because I was the one who pushed that topic with Aleix). Tuesday morning will be dedicated to Kube, and where I’ll spend the afternoon mainly depends on whether I’ll be elected into the KDE e.V. board at KDE e.V.’s Annual General Meeting this Thursday. Wednesday morning will be all about Discover.

Had I known there were so many important BoFs for me, I’d probably have stayed longer than Wednesday evening, but that wasn’t clear yet at the time I booked my travel, so I’ll have to make as much of the first three BoF days as I can.

Aside from all that, there are of course lots of hallway discussions (Akademy is always great for those!) as well as lots of fun to be had!

It will be great as always, I’m really looking forward to the second half of this week and the first half of the next one.

See you in Berlin!

Posted in KDE

A Usability Guy’s Journey to Creating his First KDE Tool – Part 2: A Vision

Advice

As already suggested in the first article of this series, fixing a bug was just the start of my journey. What I now want to do is help KDE improve our AppStream metadata. Why is this so important to me?

I first got in contact with AppStream as part of my interaction design work on Discover. The fact that all I had for linking the word Discover to was a not very informative quickgit project page perfectly exemplifies one of two big problems that I want to help solve: That only a minority of KDE projects have a proper representation on the web. The other issue is that the default software centers for Plasma (Discover) as well as GNOME and Unity (both use GNOME Software) both draw the information they present on applications from AppStream data, but far from all of KDE’s applications provide these data.

The nice thing is that we can reuse the information for AppStream to automatically create a website for each application which is at least a lot more informative for end users than what quickgit provides. Of course, those projects who have the manpower and motivation to create gorgeous websites like that for Minuet or Krita should still do that, but the others would still get at least something useful.

Of course I am aware that AppStream metadata do not grow on trees. Someone has to write them. AppStream database builders read metadata about an application from an appdata.xml file provided with the application’s source code. Now I know that just seeing the extension “.xml” is enough to raise many developers’ neck hair. The fact that developers have to write an xml file by hand may be one of the reasons why not everyone does it.

It may not be the only reason, though. Maybe people need to be reminded that they should check before release whether their AppStream data is up-to-date? Maybe they need AppData generation and maintenance to be better integrated into their workflow?

I want to help developers to create and update their applications’ AppData more easily, and I want to create a tool for that. For now I’ll call that tool AppData Helper.

This is its product vision:

AppData Helper is a tool that makes it easy for application maintainers and developers to create and maintain an AppData file for their application. It takes as much of the “bureaucracy” out of the process as possible, allowing them to focus solely on the actual information they have to provide.

Now I have two questions for you, dear potential users. First of all: Do you think such a tool may make it more likely that you provide AppData for your application? Please answer that question in the poll below. The second question is: What specifically would such a tool need to do in order to be of help to you? Would it have to be a GUI application, a command-line tool/script, a KDevelop plugin, or something else? Please provide input for that in the comments!

Thank you,

Thomas

Tagged with: ,
Posted in KDE

A Usability Guy’s Journey to Creating his First KDE Tool – Part 1: Baby Steps

path

I, psychologist by education, human-centered interaction designer by trade – my only completed software project so far being a web-based Advent calendar I made years ago – have embarked on a journey to write my first KDE tool. How did it come to this?

It all started with me wanting two things:

  1. To change the speed of Plasma animations on my system
  2. To have proper AppStream metadata for KDE software

These two may sound completely unrelated at first, but they both were key in sending me down this path. This article will tell the story behind 1, which is about my very first code commit to KDE. I will go into quite some detail because I feel that my journey may provide some insights for KDE.

This story started on April 6th. I was discussing with Aleix Pol about actual vs. perceived performance in Plasma and other KDE software. One thing we agreed on was that animation speed has a big impact on perceived performance. During that discussion, we found out that the setting for the animation speed is almost impossible to find in System Settings, because it sits in a module where you would not expect it to be (Display and Monitor > Compositor), and searching for “animation speed” points you to the wrong module (this was due to an oversight when the “Desktop Effects” module was split in two and the search keywords were not adapted). The “it sits in an unexpected module” problem is about to be fixed by moving it into the “Workspace behavior” module, but first I wanted the actual bug with the search pointing to the wrong module to be fixed.

At first, as usual, I wrote a bug report about it. Then, Aleix, being a cunning little Spaniard (*scnr*, I know you’re Catalonian), said these fateful words: “You could fix this one yourself!”. Now the cunning part was that he knew I could not defend myself by saying “But I don’t know C++ …” because the search keywords are defined in .desktop files, easily read- and writable for mere mortals like me. So, without any good argument why I couldn’t, I set out to fix it myself.

The first obstacle on my journey was that even after years of being a KDE contributor, I still did not have a KDE developer account. The reason is simple: My contributions usually come in the form of text and mockups, not code. I describe my ideas in wiki pages, emails, forum posts, chats, review requests, bug reports, blog posts, …, but not in repositories. For this simple patch, I could have just put it up on Reviewboard or Phabricator and have someone else commit it, but if I was going to contribute code, I wanted to do it properly™.

Besides, I saw an opportunity in this exercise: We often hear that while new contributors perceive KDE as a very friendly and welcoming community, they perceive the organizational process of becoming a KDE contributor as relatively difficult, and now I could experience that process first-hand and see what could be improved. So I wanted to go all the way.

Now first of all, I needed to get a developer account. I know that community.kde.org is supposed to be the place where every information for the community can be found, so I looked there. The “Get Involved/development” page looked promising. And indeed, this had a link to the “Get a Contributor Account” page. Here I found the first inconsistency: On the page, it was called a “contributor account” whereas in the actual application process it’s called “developer account”. I have fixed that now, changing (hopefully) all of it to “developer account”. “Developer account” made more sense to me, because – as evidenced by for example by me – not all contributors need such an account. Apart from that, though, the documentation there was pretty straightforward.

With that and Aleix’s blessing, I had my Developer account created the next day. Now the more difficult part was setting up Git.

The “Get a Contributor Account” page (which will hopefully soon be renamed by someone with the necessary privileges) had a link to a “next tutorial” in the “And now?” section which in turn was just linking back to the page you came from, along with something about me having to adapt my local copy to a new server (without further specification). I did not understand that part, so I asked Aleix what it meant and now we have made it more specific.

Olivier Churlaud, our new Master of the Wikis, then pointed out to me that the best pages for further information would be the Git or Subversion pages, depending on the project one wants to contribute to, so I’ve now linked to those from the “And now?” section.

So, next step, setting up Git. I followed the steps in the “Git Configuration” page, which involved a tedious amount of “git config –global” commands. I wonder if maybe we should provide a template .gitconfig file to make this easier, at least for things that are ideally the same for anyone, anyway? One of the instructions in there told me to enter

git config --global user.name <Your Real Name>

so what I entered was

git config --global user.name Thomas Pfeiffer

Following the instructions by the letter bit me in the behind later on when I tried to commit, because of course Git ignored the last name after the space and then the server could not identify me. Without Aleix’s help, I’d never have been able to identify the problem, let alone fix it.

This may all be obvious for seasoned shell users, but it clearly wasn’t obvious for me, so I changed the instructions on the wiki to

git config --global user.name "<Your Real Name>"

just to remind people to put their name in quotes.

The page also recommended to use the Git commit template from kdelibs. This sounded  outdated to me given that kdelibs is long deprecated by now, but since I wasn’t aware of any other commit template, I went ahead and used the one from kdelibs, anyway. I’ve now started a discussion on the kde-devel mailing list regarding where we should put that template in the future.

Aleix suggested that I’d use Arcanist to link my commit to a review on Phabricator, but since I didn’t want to install another tool just for my one commit (and Arcanist was never mentioned in the pages I’d come across on the wiki, either), I decided to skip that for the time being. So I manually created a Diff on Phabricator (like the “Get Involved/development” page had told me), which was reasonably simple.

Now it was time to actually commit and push my changes. For that, the page “Infrastructure/Git/Simple Workflow” sounded like the most fitting one to follow. I did what I was told there to add and commit my change. Now for the commit message. Following the link trail from the Simple Workflow page lead me (through one unnecessary hoop which I’ve now cut out) to the “Special keywords in GIT and SVN log messages” section of the “Commit Policy” page.

There I found what I was looking for, except for how to link to the Diff on Phabricator (I’ve added that now). With my commit message complete, I could finally push. I was asked whether I should add the server with the fingerprint SHA256:75pLvlr+9A0ki9YlWAz+il4UPI+N81uMvcocs42d0wU to my list of trusted servers. I remembered that the Git Configuration page had also mentioned server fingerprints, but unfortunately, those did not match the fingerprint Git presented to me. Aleix told me that the server was okay and the page was just outdated. Accepting a fingerprint which does not match the one you find in the documentation of course defeats the purpose of putting fingerprints in the documentation in the first place, so we have to either remove them from the wiki (I did that for now) or find a way to keep them up to date.

Now, finally, my first commit was pushed! Closing the bug automatically failed, unfortunately, because I had not heeded the advice in the page about getting a developer account which said “Also note that this email address should be the same one that you use on bugs.kde.org“. This one’s on me, then.

So, this is the story of my very first commit to KDE! I learned a lot along the way, uncovered some slight shortcomings in our documentation and fixed most of them. I can say that trying to relive the first contribution experience first-hand is a good lesson for anyone who cares about improving it.

In the next posts of this series I will expand on that by creating my own little tool for making the creation and updating of AppStream metadata for KDE applications easier, and I will be doing it in the way I know best: the user-centered way.

Have you started contributing to KDE recently, or know someone who has? If so, please let us know about your experience! What went well, where could we improve our onboarding process in KDE? Tell us in the comments!

Tagged with:
Posted in KDE

Do Plasma users know all the useful shortcuts?

shortcut2

“keyboard shortcut bulletin board” by arvind grover

Dear reader,

when Heiko Tietze and I discussed the usefulness of a user assistance feature that is being considered, we realized that we had very different assumptions about how well users know the keyboard shortcuts that KWin and Plasma offer.

Although I know that the readership of my blog is not exactly representative of the Plasma and KWin user base, I’d like to get at least a rough feeling about whose perception might be closer to the truth. For that, I need your help: I’d like to ask you to do the following:

  1. Go to System SettingsShortcutsGlobal Keyboard Shortcuts
  2. Select “KWin” in the “KDE component” dropdown
  3. Go through the shortcuts which have a “Default” value set and count those which you did not know by heart (or not at all) but think could be useful to you.
  4. Do the same for the “Plasma” component
  5. Add the two numbers
  6. Select the appropriate option in the poll below.

If you know any Plasma users who don’t read Planet KDE / my blog, it would be great if you could link them to this.

Thank you!

P.S.: Sorry for the confusion I might have caused with the picture above. It has nothing to do with Plasma or KWin, actually. I just wanted a nice picture, and I explicitly did not want to show any Plasma or KWin shortcuts in order to not influence the experiment.

Tagged with: ,
Posted in KDE

Plasma Mobile’s Vision

We’re currently in the process of designing the first phone user interfaces for KDE applications, applying the KDE Mobile Human Interface Guidelines (a set of soft rules and recommendations for designing user interfaces for mobile applications by KDE). Therefore, the third part of my blog series about the HIG creation still has to wait a bit.

In the meantime, I’d like to talk a bit about another foundation on which Plasma Mobile is built: Its vision. As I’ve already laid out in my blog post about creating a vision for the KDE PIM Framework, a vision is very important to align the work in a project towards a common goal, and to inspire those contributing it. Inspired by the talk Andrew Lake and I had just given at Akademy about product/ project visions, it did not take much convincing to get the Plasma Mobile team to start working on a vision.

Shortly after Akademy, I met online with Sebastian Kügler, Ivan Čukić and Jens Reuterberg to draft a first proposal for the vision, along with potential target personas. The result was then presented to the Plasma mailing list, where it was well received, and consequently adopted with only with minor revisions.

And here it is, our vision for the future which guides the design and development of Plasma Mobile (this does not say when Plasma Mobile will meet these goals):

Plasma Mobile aims to become a complete software system for mobile devices. It is designed to give privacy-aware users back the full control over their information and communication. Plasma Mobile takes a pragmatic approach and is inclusive to 3rd party software, allowing the user to choose which applications and services to use. It provides a seamless experience across multiple devices. Plasma Mobile implements open standards and it is developed in a transparent process that is open for the community to participate in.

These are the four key elements:

1. Control over your data and communication

monitor-1054708_640

With most current mobile operating systems and applications, users can only trust those who create them that they will not abuse the detailed and sensitive information that is stored on their devices, and the communication that happens through them.

When installing an app, we can see the – vaguely defined – permissions that the app requires, and – depending on the operating system and version – we can either decide whether to take it as it is or to leave it, or we can block certain permissions. But beyond that, we can never tell what exactly happens with their information and communication. Which files or records are accessed? Where is information stored, and who or what may access it in the future? Where is information sent? Is the communication secure and private? We simply cannot tell. We can only trust others that they do what they say they’re doing.

In Plasma Mobile, we want to change that. We want users to be able to see what happens to their information and communication, to the degree of detail that they prefer. They should be able to allow an application to access some files, but not others, and they should be able to control when and where their information is sent.

We do not want to overburden users with feedback and choices they cannot handle, though. Our aim is to present the information and choices as clearly as possible, and give users a choice only when they want to have one.

2. Pragmatic and inclusive

welcome-sign-760358_640

We are realists. We know that a mobile operating system is nothing without apps. And we know that we, as a community, cannot provide applications for everything that users may want an app for. We aim to provide our own apps for the most common tasks (e.g. browsing the web, viewing common file types, email, calendaring, instant messaging, …) in order to create the most seamless experience possible across them, but the more specialized a task or service, the less likely we’ll be able to provide an app for it ourselves.

For that reason (and because we believe that choice is a good thing), Plasma Mobile won’t exclude any application as long as it’s technically possible to run it (and it’s not malware), whether it was written for Plasma Mobile, Android, Ubuntu Touch, desktop Linux, Sailfish or whatever. If it can be made to run on Plasma Mobile, it’s welcome there!

Pragmatism also means that we won’t keep users from giving up part of the control the system offers them again, by running proprietary applications or accessing services on it which invade their privacy. We will strive to keep those applications as sand-boxed as possible, but we won’t keep users from doing something with their device which we wouldn’t do.

3. Seamless cross-device experience

Cross-device

When using Plasma on multiple devices, we want those devices to feel really integrated. KDE Connect already offers impressive integration between a Linux desktop and an Android mobile device, but with a platform that we fully control, we can still go beyond that (users could fully control their phone from their desktop, for example, or tethering could be made a one-click experience). Your selection of applications or certain settings could be synchronized between your desktop or tablet and phone (yes, that one is not new, other mobile OSes can do that already), or a desktop application can suggest to automatically install the corresponding mobile application on your Plasma Mobile devices (for example when an office suite offers a mobile “companion” for controlling presentations).

“Seamless experience across multiple devices” also refers to the same application binary offering an optimized experience on different form factors through interaction-shifting components (user interface elements which change their look and behavior depending on the type of device) and adapted QML files. For example, while contextual actions are offered using a side-drawer or “slide to reveal” controls on a touch device, the good ol’ right mouse button is much more convenient when using a mouse. Another example is scrolling: On a touch-based device flicking is the best way to scroll, whereas with a mouse, the combination of scroll wheel and a traditional scroll bar still works best. The general layout of content or the navigation structure, on the other hand, can often be kept the same across devices, allowing the user to transfer their knowledge from one type of device to the next.

4. Openness

open-966315_640

Yes, we do realize that Plasma Mobile is not the only open source mobile shell. The Android Open Source Project is, as the name implies, open source. Yet, most of its development happens behind closed doors at Google. That means that even though anybody can do anything they want with the end result, people outside Google cannot freely contribute to it or influence any decisions. Sailfish OS has a fully open base, but the user interface layer is still proprietary. Tizen or Ubuntu Touch are perhaps more open, but still mostly in the hands of commercial entities.

Plasma Mobile wants to be different. Even though Blue Systems initiated the development, it is explicitly not a Blue Systems product (otherwise it would probably be called Netrunner Mobile). Blue Systems of course will only contribute their resources to efforts that are in line with their goals for Plasma Mobile, but they will not keep anyone from working towards their personal goals for Plasma Mobile in their own time.

Plasma Mobile was, is and always will be a community project. All of its development happens in KDE repositories where everyone with a KDE developer account has write access, and all commits can be reviewed by the community. All of its components are Free Software.

An equally important aspect of Plasma Mobile is that it uses open standards. Android is Linux, but one only realizes how important the “GNU” part of “GNU/Linux” is to the actual experience of a regular GNU/Linux distribution once that isn’t there.  Other mobile operating systems are closer to the stack we’re used to, but still diverge from standards that are or will be well established in the desktop world, like Wayland Display Servers. Plasma Mobile aims to make it as easy as possible for developers who have previously worked in the desktop area to transfer their knowledge (and code).

Concluding remarks

So this is what Plasma Mobile aims for. Whenever we make important decisions, we will check whether they are in line with the vision. People are of course free to spend their time on things which do not necessarily get us closer to these goals, but we would not allow things which work against them.

Now, I’d love to hear whether these goals are in line with what you’d expect from Plasma Mobile or what we might have missed.

 

Tagged with: ,
Posted in KDE