Guerilla UX Testing, and Other Experiences From Akademy

It’s about a month now since the end of Akademy 2018 and I’ve finally found the time to write up some of my impressions from my favorite event of every year, and to encourage all of you to embrace both your inner User Experience (UX) Researcher and your inner guerilla.

My Talk: Guerilla UX Testing

che-155389_1280.png

“Che Stallman”, CC0 from Pixabay / openclipart

I usually try to give at least one talk at each Akademy I attend, and this year I wanted to shake up the way KDE approaches UX design and research a bit again. The idea to give a talk about Guerilla UX came when we had one of those design discussions on Phabricator where different sides of the discussion had different ideas in their minds of what The User™ would want or need, and we had no way to tell which side knew our users better, or even if either side knew them well at all.

Usually, a UX person’s reaction (at least if they don’t suffer from delusions of grandeur) to such situations is “Why don’t we just test it with actual users?”. As a distributed community of mostly volunteers with limited personnel and monetary resources, however, this is much easier said than done. This is where Guerilla UX Research comes in: According to UX Magazine “Guerrilla research is a fast and low-cost way to gain sufficient insights to make informed decisions.”

In short: Guerilla Usability / User Experience Testing has you walk up to someone resembling your target audience (can be a stranger, can be someone you know as long as they are not aware of what you’re currently discussing), show them the product / UI / design you want to find something out about, give them a task and watch them use what you’ve made, recording any user experience issues you notice.

This is often all we need: A relatively quick and cheap way to gain some insight into how our users think and behave, even if the insight is only limited. It’s not as good as detailed user research with specifically selected participants, but as long as the test participants are at least similar enough to the actual target audience, it’s definitely better than generalizing from the project team’s own experience to that of the target audience.

I’d therefore heartily encourage everyone who needs to design a user interface or decide on features and isn’t 100% sure what their users need to take maybe a day (or maybe an hour each if you split the task among the team) to perform some guerilla user testing. I can promise you that you will be surprised by the results and that you will have fun!

For more details see the slides from my talk:

(in case the embedded viewer doesn’t work for you, here are the slides on Slideshare)

Akademy from the Perspective of a Board Member

This year’s Akademy was especially interesting for the board of directors of KDE e.V.. in several ways.

Sponsors Dinner

On Saturday, we could witness first-hand how KDE is able to connect different organizations: At the sponsors dinner, where representatives from all of Akademy’s sponsors spend an evening together with the board to share our ideas and projects.

I had the opportunity to sit at a table with representatives from four companies that are active in the hardware business and all are connected to KDE now: Blue Systems, Mycroft, Pine64, Purism and Slimbook. It was really cool to see the people from the different companies discuss their plans and their experiences with trying to make hardware in a FOSS-friendly, user-freedom-respecting and ethical way. All of them had already heard of the other companies before, but most of them had never met in person before, so we really had an effect there.

Annual General Assembly

On Monday, we had KDE e.V.‘s Annual General Assembly (the official minutes in German can already be found on our website, the English translation is still in preparation). For me personally, the biggest event of the AGM was the election of a new board member to replace Sandro Andrade, whose term had ended (thank you again for your great work on the board, Sandro!).

Before the AGM, Andy Betts was the only candidate for the position. Not really a problem since Andy was a great candidate, but an election with only one candidate where all one can do is vote for or against that candidate always feels a bit weird to me. That’s why I was happy when Tomaz Canabrava spontaneously stepped up as a second candidate during the AGM. Now we were in the comfortable position of having two excellent candidates to choose from.

After a great Q&A session with both candidates, Andy won the election. I’m very happy to have Andy on the board, though I would have been equally happy with Tomaz.

Meeting with The Qt Company

Right after the AGM, the board met with a delegation from The Qt Company (which included their CEO and CTO) to discuss how we can collaborate to make sure that Qt continues to serve both the needs of The Qt Company and those of KDE (and the ecosystem of Qt users as a whole).

We learned a lot about The Qt Company’s plans and the challenges they’ve overcome and are still facing, and were able to share our experiences as one of the key players in the Qt ecosystem. Overall it was a very informative and constructive meeting, and we’re looking forward to continue collaborating with The Qt Company toward our common goal: To keep Qt as great as it is!

My Highlights from the BoF Days

Unfortunately the meeting with The Qt Company coincided with two BoFs that I had really wanted to attend: One was about the VVAVE project, a very promising KDE music player and music discovery platform created by Camilo Higuita, the other was about the newly-rebooted KDE Human Interface Guidelines. I had contributed a lot to the original content of the HIG but haven’t had much time to work on it recently, so I’m eternally grateful that Fabian Riethmayer took over maintainership and is putting countless hours of work into them.

I spent the first half of Tuesday in two sessions about the current state and goals of the VDG (and Plasma design topics in particular), led by Andy, and the second half discussing mobile and convergence topics in the sessions about our convergent UI toolkit Kirigami UI (led by Maco Martin), and about the MauiKit (led by Camilo) which extends Kirigami further. We discussed what we consider to be the defining attributes of Kirigami, what the commonalities and differences between MauiKit and Kirigami are, and how to make sure that both users and developers have the best possible experience across both.

Trainings

Thursday, my last day at Akademy, I spent in the Online Fundraising and Campaigning training, led by Florian Engels from more onion (via NPO academy). All participants agreed that we learned a lot of practical strategies and tips for fundraising and campaigning, which we are sure to apply in the coming campaigns for KDE, Krita and Nitrux!

I also heard a lot of positive feedback on our other trainings: The training on Nonviolent Communication by freelance communication trainer Tilman Krakau, the Technical Documentation Training by Stefan Knorr from SUSE’s documentation team, and the Public Speaking training by Marta Rybczynska, technical public speaker and trainer, and active member KDE.

Since I was in charge of setting up the trainings and this was (as far as I know) the first time KDE offered professional training to our contributors at Akademy, I’m glad that they seem to have worked out very well!

Conclusion

As in every year, this was again a very successful Akademy, with lots of productive discussions, interesting talks, great conversations with friends over dinner and beer, and overall a wonderful time!

 

Advertisements
Tagged with: ,
Posted in KDE, User Experience

Retrospective: The KDE Mission Survey

It might sound a bit weird that I’m now talking about something that took place two years ago, but I just realized that while the call to participate in the survey for the KDE Mission was published on the Dot, the results have so far not received their own article.

People who have participated in the survey but don’t read the Community list might have missed the results, which would be a pity. Therefore, I’d like to offer a bit of a retrospective on how the survey came to be and what came out of it.

The Backstory

To recap a bit on what lead to the survey: After we had finally arrived at a shared Vision statement for KDE in April 2016, the next step was to distill the more high-level Vision into a more concrete Mission statement. We started brainstorming content for the Mission in our Wiki, but soon realized that there were diverging viewpoints on some issues and the relatively small group discussing them directly on the mailing list wasn’t sure which viewpoint represented the majority of the KDE community.

We also wanted to know what our users care about the most. Although in the end it’s the community who defines our Mission, we don’t make software just for ourselves, so we hoped that our goals would align with those of our users.

The Survey

To find out what is most important to the community at large as well as our users, I applied one of the standard tools in my belt: An online survey, in which participants indicated their perceived importance of goals that were brought up in the brainstorming, as well as the perceived usefulness of several measures towards achieving each goal. They also gave their opinion on a few of the contending viewpoints from the brainstorming, as well as on the importance of certain target audiences and platforms.

A few demographic questions, such as whether participants identified as users of or contributors to KDE software, how long they had been using and contributing to KDE software, as well as in which area they contribute or whether they do it as part of their job, aimed at making sure that our sample isn’t skewed toward certain groups.

We invited participants via the aforementioned Dot article, several big KDE mailing lists as well as Google+ (where we have a pretty lively community).

Analysis

I ran series of one-sample t-tests (with Benferroni correction) to check whether the sample averages for the importance ratings were significantly different from the scale mid-point (4 on a 7-point scale). I did that instead of a within-subjects ANOVA because we cared about whether each goal or means was above- or below-averagely important to the KDE community more than than about how they compared to each other.

Furthermore I compared the two variables representing both sides in each case of contending viewpoints using a paired-sample t-test.

Results

Sample

We had 201 currently or formerly active KDE contributors participating in the survey, as well as 1184 interested users.

Demographics showed that no particular group of people dominated our sample in any of our demographical variables (other then users vs. contributors, which were analyzed separately anyway).

Some result highlights

I will only report a few interesting highlights in this post, please see the full report here for all results. If you want to do your own analysis, you can find all data here.

 

Chart showing the perceived importance of several proposad goals

Perceived importance of several proposad goals (click to enlarge)

The importance of the goals turned out to be quite similar between contributors and users, with creating software products which give users control, freedom and privacy, as well as providing users with excellent user experience and quality being the most important for both groups. Contributors rated all goals’ importance as significantly above the scale midpoint. The biggest difference between users and contributors is on  whether we should reach as many users as possible, with users rating it much lower than contributors. This is to be expected, as current users naturally don’t care much about whether we try to reach other users.

Chart showing the agreement with contending viewpoints

Agreement with contending viewpoints (click to enlarge)

Regarding the contending viewpoints within the brainstorming group, the survey showed a statistically significant preference among the KDE community at large for one of the viewpoints in three out of four cases: On average, the community shows a preference for focusing on applications covering our users’ most common tasks, for covering GUI applications as well as non-GUI applications, and for focusing on Qt. The community seems largely indifferent about whether we should strive for consistency between KDE GUIs across platforms, or for adherence to specific platform guidelines.

Chart showing relative importance of different target operating systems

Relative importance of different target operating systems (click to enlarge)

When it comes to which operating systems we should target, GNU/Linux is still preferred by a large margin, followed by Android according to our contributors, and by *BSD and other Free operating systems according to our users. There was a big difference in perceived importance of Windows, OS X (now macOS) and iOS, showing that KDE contributors are on average far more interested in supporting proprietary operating systems than our current users are. One possible interpretation of that could be that the KDE community takes a more pragmatic approach to OS support, whereas our current users take a more ideological standpoint. A different interpretation would be that our users care about what they currently use, and while Windows and macOS has seen some support by our applications, the userbase on those is likely comparatively small.

Chart showing relative importance of different target audiences.

Relative importance of different target audiences (click to enlarge)

An interesting finding was the very close match between contributors and users when it comes to the importance of different target audiences. This shows that apparently, KDE has so far reached pretty much exactly the users we aimed for.

Overall, the results confirm that the ideas coming out of the brainstorming are mostly shared by the wider community as well as our users. They also show that the KDE community has some ambition to expand our userbase and target platforms beyond what we serve today, but still wants to stay true to our roots such as Qt.

What Happened Next

The full results were presented at an Akademy BoF session to discuss the KDE Mission, as well as to the Community mailing list. They were used to guide the further discussion that eventually lead to KDE’s Mission and Strategy statements.

Tagged with: , ,
Posted in KDE

Hey Mycroft, Drive Me to our Goals!

Intro

Almost three months after Akademy 2017, I finally found the time to write a blog post about how I experienced it.

Akademy is where I learn again about all the amazing things happening in our community, where I connect the dots and see the big picture of where all the effort in the various projects together can lead. And of course, I meet all the wonderful people, all the individual reasons why being in KDE is so amazing. This year was no different.

Some people voiced their concern during the event that those who are not at Akademy and see only pictures of it on social media might get the feeling that it is mostly about hanging out on the beach and drinking beer, instead of actually being productive. Everyone who was ever at Akademy of course knows this impression couldn’t be further from the truth, but I’ll still take it as a reason to not talk about any of the things that were “just” fun, and focus instead on those that were both fun and productive.

Tales from the KDE e.V. Board of Directors

One thing that happens at every Akademy is the Annual General Assembly (AGM) of the KDE e.V.

This association, usually just called “the e.V.” by the community, is KDE’s legal and financial representation. Among other things, it raises funds and uses them to make in-person meetings within KDE happen, such as developer sprints or conferences, and sponsor attendees who cannot afford travel and accommodation for those themselves. It also takes care of legal issues such as maintaining KDE’s trademarks, and this year it also uses some of its funds for two marketing contractors, Ivana and Paul, to help push our promo efforts. Since last Akademy I am on the board of directors of the KDE e.V., so the AGM is especially important to me.

One important aspect of this year’s AGM was that three out of the five positions in the board of directors were up for re-election. Two of the board members whose terms ended, our president Lydia Pintscher and vice president Aleix Pol, ran for another term and were re-elected, whereas Marta Rybczynska was not able to run for another term as treasurer, and is now followed by Eike Hein. Eike used to be one of the “KDE phantoms”: He’s been a very active KDE contributor for many years (most notably the maintainer of Konversation, Yakuake and several key parts of Plasma such as the Task Manager), but the majority of his fellow KDE members have not seen him in person until this year.

New Board 2017.jpg

The new board (from the left): Eike, yours truly, Aleix, Lydia and Sandro

Fortunately I had the opportunity to talk to Eike more than anybody else at this Akademy because we had been assigned as roommates. He had lots of interesting stories to tell, from the way IRC facilitates building communities, to communication culture in Korea (where he now lives), to the experience of moderating multiple Subreddits, and much much more. I’m really looking forward to working with Eike on the board!

My highlights from two days of talks

The following are explicitly my personal highlights. If you’re a non-programmer like me, who is also especially interested in design and/or in KDE software running on anything that isn’t a traditional desktop or laptop PC, chances are you might find those talks as interesting as I did. If you know more about programming than I do, you’d also enjoy a lot of the other presentations, where I could just sit and be amazed by how people like you can understand all of that technical stuff.

So, here goes:

Aleix Pol’s talk about A laptop by KDE  summarized our experience with the KDE Slimbook, the very first KDE-branded hardware on the market, and gave a few ideas on what we might do next in that area. This was especially important to me because I was deeply involved in promoting the KDE Slimbook initiative. The talk was followed up by a BoF session during the week where we did an in-depth retrospective on how the Slimbook project went so far and what we learned from it.

A talk which was especially relevant for me as a user researcher was the one on (K)UserFeedback, where Volker Krause introduced the new framework that allows applications to – after opt-in and fully anonymized, of course – collect usage data and send them to KDE to use it for improving our software. Given that privacy is at the core of our Vision and Mission, of course we are extremely cautious in that area, but some usage data is needed for us to make software that fits the needs of our users, not just our own. Volker’s talk was accompanied by a BoF on Tuesday where we discussed what our policy on collection, storage and use of that data should look like in order gain useful information without compromising our users’ privacy.

A talk which was interesting for me from a strategic, design and user perspective was the one about Mycroft AI Plasmoid & Plasma Desktop Integration, in which Aditya Mehra presented some of the amazing things the Mycroft AI can already do in Plasma, as well as his plans for the future. Digital Assistants are one area where the Linux desktops clearly lag behind all big proprietary operating systems. Many Free Software proponents reject digital assistants outright due to a perceived inherent privacy problem, but Mycroft (apart from currently using a Google service for speech recognition, but there are plans to replace that) shows that privacy-protecting and fully user-controlled digital assistants are possible. That is why from my perspective, this is a hugely important strategic area for KDE. This talk was also accompanied by a BoF on Tuesday, about where else in Plasma we can use Mycroft’s capabilities. If you are as excited as I am about the role KDE could play in Free Software solutions for AI and home automation, consider participating in the discussion on my community goal proposal on that subject.

Aditya giving his talk about Mycroft

In his talk Opening new doors: KDE in embedded, Agustin Benito Bethencourt presented some of the ways in which KDE could play an important role in the world of embedded systems, for example in the automobile industry. He has been involved in two different projects in that area and told us that the industry is waking up to the benefits of open source, and that from his perspective, now would be a great time for KDE to make ourselves known in that space. This talk, too, was accompanied by a BoF session, where we discussed next steps for getting our software to run on automotive systems. This is also an area where I believe it’s important that KDE champions Fee Software, because, like with virtual assistants: What have we won if our PCs and phones run Free Software, but our cars are not in our full control and might even spy on us? If you are interested in this project, head over to the Automotive project on Phabricator and join the discussion and work there!

In his talk Looking for Love, our marketing contractor Paul Brown taught us the importance of focusing our communication strategy on the users’ needs, by presenting, in clear and easy to understand words, what benefit our products bring to them, instead of trying to describe their purpose as precisely as possible from our own perspective. That he took the Kirigami wiki page, which I had contributed significantly to, as a negative example of a description which uses way too much jargon and focuses on technical details instead of user benefits, of course meant that I had to endure seeing one of my “babies” being ripped apart in front of my eyes, but it was definitely worth it! The talk was meant as an appetizer for a workshop on Monday, were Paul helped everyone who wanted to improve their product website.

In his talk Input Methods in Plasma 5, Eike Hein made it clear that the state of input methods (which are needed primarily for text input in e.g. many Asian writing systems, but can also handle things such as emoji input or auto-completion or -correction) in Plasma and KDE applications is currently lagging behind other popular operating systems and desktop environments. He presented what needs to be done to improve the situation, and is now rallying people behind a proposal for a community goal to make it happen together. So here as well: If you also feel that improving input methods in KDE software is important, join the conversation on the proposal!

Camilo Higuita, author of the Babe music player, gave a talk Introducing Babe and a contextual approach to multimedia desktop apps where he demonstrated how Babe uses various techniques and online services to find connections between songs in order to give smart answers to search queries. His talk was also accompanied by a BoF session during the week, where we discussed some design ideas and how to use Kirigami to make Babe a convergent desktop and mobile application.

Yours truly also gave a presentation, together with Dan Leinir Turthra Jensen, titled Folding Your Applications, where we talked about the design behind the Kirigami Ui framework and how application developers inside and outside of KDE are already using it to easily create mobile and convergent user interfaces.

Putting Ideas to Action: The Workshop and BoF Days

Monday through Thursday were dedicated to workshops and Birds of a Feather (BoF) sessions, where various groups in KDE – established project teams, groups spontaneously forming around a topic, or often a combination of both – discussed how to drive their ideas forward.

In addition to the already mentioned follow-up sessions to talks from the previous days, these were the sessions that inspired me most:

In the Plasma Mobile part of the Plasma BoF, we learned about Plasma Mobile’s current status and discussed what needs to be done next. There is also a proposed community goal to improve the Plasma Mobile platform for end-user needs, so if you agree with me that Plasma Mobile is of strategic importance to KDE, please participate in the discussion there!

If you ask yourself what the deal is with all those community goals I keep referring to: The initiative to define some concrete mid-term goals for KDE for the next 3-4 years was actually born at Akademy, during a BoF titled ‘”Luminaries” Kabal Proposals’, where Kevin Ottens, Frederik Gladhorn and Mirko Boehm presented to us what came out of their discussion about how they think KDE can be put on the right track towards the future. The goal-setting initiative was one of their proposals. Another one was integrating the KDE e.V. working group reports, which have so far been part of the AGM, into the general conference schedule, allowing people who are not members of the KDE e.V. to learn what’s happening there, as well as significantly shortening the AGM. This proposal will be implemented at next year’s Akademy. Their third proposal, making sure the barrier of entry to contributing to KDE is as low as possible, has been picked up in two goal proposals (which are likely to be merged into one), so, once more: If you agree that this is important for KDE, join the discussion over there!

In a BoF titled “Visual Design Direction”, Andres “Andy” Betts brought up some ideas on how to better integrate designers into the Plasma development process again, and volunteered to spearhead the next round of design improvements. Andy has also submitted a goal proposal related to this, so… you know the drill by now.

BoF wrap-up session, where BoF leaders summarize the results of their session to the rest of the attendees

Closing Words (and a shameless plug)

Now that I’ve advertised various community goal proposals here (one of them being my own), let me use the final paragraph to link to my other proposal, Making KDE software the #1 choice for research and academia. This goal aims to give KDE software the exposure in the research and academic sector that it deserves due to its features and quality, but currently does not have. I think KDE has a lot to offer to researchers, teachers and students, so I’d like us to get in touch with them, promote our software to them and improve it based on their direct feedback. If you agree, participation is welcome!

With hat out of the way, I can summarize that this year’s Akademy was a very successful event, despite being slightly smaller than usual (due to the location being a bit hard to reach and the timing falling into vacation time for many KDE members). I’m now full of enthusiasm again about the things to come for KDE, and looking forward to next year’s Akademy in Vienna!

Tagged with:
Posted in KDE

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’!

Tagged with: , ,
Posted in KDE

The Quest for a Common Chat/IM Solution

Konqi between dchat solutions

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