obso1337.org

In addition to talking about the KDE Usability Project at Akademy 2008, Ellen and I hosted a KDE HCI Workshop.

90% of what I do as a designer is to try and understand problems and solve them. There are several research and design methods I use as a designer which can be simplified and modified in a way that developers can use them as well. In my workshop session, I gave developers several participatory and non-participatory methods they could use to help make more usable software. Here are 6 methods developers can use to help improve the usability of their software. These methods offer options which need no users, require user participation, are useful for user research, or are helpful in design and testing.

What is User-Centered Design?

User-centered design (UCD) is a methodology which considers the user’s needs, goals, and tasks throughout the development process. Basically, you want to keep the user in mind while you are planning and creating a product for them. You try to answer the What, Why, and How by understanding the Content, Context, and Use of a product in terms of its users.

Many of you are familiar with this comic.

UCD is understanding what the user really needs. UCD is also more than just usability testing. Usability testing is simply one of many methods interaction designers and usability engineers use to help create usable products. There are two classes of methods we use in UCD, participatory and non-participatory methods.

Types of Design Methods

Participatory methods are methods that users have an active role in design and development. Users become design partners and are involved in the planning, design, and testing stages the development cycle. Participants can be current or prospective users. Participatory methods include usability testing, surveys, and interviews.

Non-participatory methods are methods where users are not actively involved in design and development. Designers and developers involved in the development cycle try to keep users in mind while they are creating a product. Non-participatory methods include creating user groups and personas, task analysis, and reviewing user interfaces.

You do not need user participation to do UCD

Once you have decided you want to do an activity to help you improve your software, you must decide what it is you want to do.

More traditional research methods help you answer questions you might have about a user group, function or configuration option, or different design solutions. Design methods help you get stuff done, by establishing a usability baseline (to see how much you improve), find usability problems to fix, and improve the overall design and usability of your software.

Interviews

Interviews are a participatory user research method, usually done early in the development cycle during the research and planning stage (but can also be used later as a way of assessing certain features or functionality). It is exploratory in nature; you are usually trying to gather information to help answer a question instead of trying to validate or prove something. The method itself is quite simple — you just talk to users. It is a good idea to focus an interview activity around a single question or topic you are trying to solve. This allows you to gather much more information about a single topic by following up with specific questions.

1. Think about the type of questions you want to answer, For example, “How do you configure X” or “What do you do when you need Y”
2. Create a list of participants to interview (try to talk to different types of users)
3. Write an “interview guide” which lists background questions for the user and your research question
4. Take notes on the interview guide, it will help you stay organized
5. Compile your notes and talk about the results with your project.

User Groups

Creating a list of user groups is a non-participatory user research method, usually done at the beginning of a development cycle. It is a simple activity which involves one or more contributors making a list of different types of users of their application. When you create your different groups, you want to consider different dimensions which can effect use such as experience, roles, tasks and activities, and environment. Although no user participation is required, interviews can help supplement information you don’t know about a particular user group.

1. List the types of users you think use your app by various dimensions
2. Think of descriptive names to give the different groups of user types you find
3. Write a one or two line description of the group
4. List the types of tasks you can complete in your app
5. Look at your user groups again and add/edit and group information
6. If more than one contributor made a list, compare your notes and create a single list
7. Share the results with the rest of the project

Surveys

Surveys are a participatory user research method you can use to ask a lot of questions and gather structured data you can analyze. They can be used to gather all sorts of data including user demographics, frequency of feature or option use, and other useful information. Be aware that mailing lists and forums may not have all of your different user types represented. Keep this in mind when you are recruiting survey participants and analyzing your data.

1. Make a list of functionality or options in your app
2. Create a web survey which asks users how frequently they user or configure each of the functionality or options in the list
3. Send the survey out to you current or potential users
4. Analyze the results and look at the data in terms of overall usage and usage per user type
5. Compare the results with your current user group data and how your app is designed
6. Discuss results with your project

Task and Screen Diagramming

Creating system diagrams of task and screen flows is a non-participatory design method. These diagrams provide a different way to view and understand processes and how complex they are (and should be). It is helpful in nearly any stage of development because it helps plan and document processes and functionality. Diagrams can be simple and drawn on a napkin, or very detailed and drawn in Kivio, Presenter, or Dia.

1. Pick a single or group of related tasks to diagram
2. Begin diagramming the different paths for completing a task. Start at a high level and add then add details
3. Analyze your diagram. How complex is the diagram? Is it appropriate for how difficult the task is?
4. Review each of your user groups. Does the task make sense for all the user groups involved?
5. Discuss your findings and ideas with the rest of your project

UI Walkthroughs

User interface walkthroughs are a participatory design and testing method which can help you test functionality or design options with real users. You literally “walk” the participant through the UI, with varying degrees of guidance depending on how functional the wireframes, prototype, or beta software is. This is a type of usability testing, but the goal is to get immediate feedback in the middle of the development cycle instead of waiting until a release to test your design assumptions.

1. Pick a single task or feature you want to test. More than one or two tasks will be too much for a single session
2. Package the test software to make it easy for users to install and test. Alternatively you can use screenshots instead of compiled code
3. Ask the user to perform a certain task without giving away too much on how to do it. Pay attention to what the user does and not says
4. Repeat for 4-5 users. You do not need many because you are testing designs and your own assumptions; you are not out to prove anything.
5. Discuss results with your project, and possibly make changes to the app depending on the results of the walkthrough

UI Reviews (aka Heuristic or Expert Review)

UI reviews are one of the most common activities I do as a designer. It is a non-participatory design method you can use to find usability issues to fix. There are many types of issues you can look for, the most typical include the 10 basic heuristics, guidelines conformance and other industry standards and best practices (ISBP). These reviews work best if 2 or more people review the UI; a single person will not find all issues in an application and it is always good to have a second opinion on a design option. Out of all of the methods presented, this is both the easiest and most difficult to do. Many low-level UI issues are easy to find and check off a list, but higher-level (more serious) conceptual issues may take experience and practice to identify. Also, since you may be able to identify something as “wrong”, but not necessarily why it is wrong, it may be more difficult to convince your colleagues that it should be fixed.

1. Choose a few tasks to help you step through the app in a structures way.
2. Look for issues relating to the 10 usability heuristics, interface guidelines, and anything that might look or feel wrong
3. Record each issue with a screenshot and description of the problem. Include ideas on how to fix the problem
4. Compile results with other reviewers and consider design fixes
5. Discuss results with the rest of your project and plan which issues to prioritize

seele :: Aug.25.2008 :: Design, General, Open Source :: 7 Comments »

After a long discussion on #kde-usability, I decided to finish writing a response to recent slashdotted article on open source usability. Canonical designer Matthew Paul Thomas recently posted his thoughts on open source usability and his ideas on how to fix them. I agree with many of his points, but would like to elaborate on some of his points. I’m also happy to see that although KDE has a lot of work to do in terms of improving usability, we don’t have the cultural/social problems he describes as barrier towards usability. We just need more people to get stuff done faster :)

1. Weak incentives for usability. Proprietary software vendors typically make money by producing software that people want to use. This is a strong incentive to make it more usable… With volunteer projects, though, any incentive is much weaker. The number of users rarely makes any financial difference to developers, and with freely redistributable software, it’s near-impossible to count users anyway…

I don’t completely agree that there are weak incentives for usability in open source. I think a lot of projects would have usability goals if they truly understand what usability is. For most of the clients and projects I’ve spoken to about what usability really is, their next question is “how do we do get started?”. You can improve usability without money or usability contributors by just understanding what your goals are and who your users are. Ellen Reitmary and I have been researching problems in open source software and nearly always usability problems (with or without designers) are linked to developers not having a clear understanding of who their software is for and what their users should be doing with it. Educating developers on how to do basic user research would be more valuable than investing in usability testing.

Reading some of the comments on Slashdot has yet again reinforced the need for more education of usability in open source software. Usability is not user option and preferences! Usability is not just about testing! Usability is not about making it so easy that anyone should be able to use it the first time! FUD has become a huge barrier for usability and makes my job harder. This feeds in to MPT’s points 2 and 3.

2. Few good designers. Some musicians are also great composers, but most aren’t. Some programmers are also great designers, but most aren’t. Programming and human interface design are separate skills, and people good at both are rare. So it’s important for software to have dedicated designers, but few Free Software projects do. Some usability specialists are employed by Free Software vendors such as Mozilla, Sun, Red Hat, and Canonical. But there aren’t many, and skilled volunteer designers are even harder to find.

Unfortunately this is a problem no one has been able to solve for the past 5 years we’ve been discussing it. Hopefully programs like OpenUsability’s Season of Usability will get more design students interested in design and keep them contributing to open source beyond the internship period. Then again, if open source usability sucks so bad, these companies ought to hire more designers to get stuff done. Usability isn’t a feature, it is a requirement.

3. Design suggestions often aren’t invited or welcomed. Free Software has a long and healthy tradition of “show me the code”. But when someone points out a usability issue, this tradition turns into “patches welcome”, which is unhelpful since most designers aren’t programmers. And it’s not obvious how else usability specialists should help out.

The problem is no one trusts anyone who opens their mouth and says “usability”. This is a cultural and social problem more than a process problem. Open source is a meritocracy, and it’s easy to prove you are a competent developer because you have other competent developers available to judge them. You can’t do that with designers (at least very easily) and so the only way to get past the cultural and social problem is to start with small contributions just as a new developer may start.

Project members aren’t likely to trust or implement a designer’s recommendations unless they know the designer has a vested interest in the project. Introduce yourself to a project. Subscribe to the mailing list and browse open bugs. Get familiar with the software and their goals. Do small UI reviews and submit bugs with screenshot mockups of recommendations. Talk to developers about UI problems and work with them on solutions, don’t just dump a report in their lap. Explain why a certain aspect of a design is good or bad so it makes sense to the developer as well. As a designer, you need to establish yourself as part of the community and as a resource, just as a new developer might.

Of course, treating designers as second class contributors is an excellent way to drive them away. We respect your job as a coder, so please respect our job as a designer. We don’t try to do you job so don’t try to do ours.

4. Usability is hard to measure. …Without frequent user testing, volunteer projects rely on subjective feedback from the sort of people devoted enough to be subscribed to a project mailing list. But what these people say may not be representative of even their own actual behavior, let alone the behavior of users in general.

Usability testing is only one method in a class of participatory methods to get user feedback. Quantifying usability is time consuming, expensive, and not well suited for highly iterative design. The real problem is we have too few people experienced in gathering and filtering user information and make it useful. I would recommend more practical methods for volunteer-based projects such as interviews and surveys which structure information and can be more easily analyzed. OpenUsability has helped several projects create user surveys and collect data. I’ve been getting users to view wireframes or download and install test packages to talk about during interviews, which is much easier to conduct and has provided some very useful feedback.

5. Coding before design. Software tends to be much more usable if it is, at least roughly, designed before the code is written. The desired human interface for a program or feature may affect the data model, the choice of algorithms, the order in which operations are performed, the need for threading, the format for storing data on disk, and even the feature set of the program as a whole… But the more code has been written, the harder it is to fix a design problem — so programmers are more likely not to bother, or to convince themselves it isn’t really a problem. And if they finally fix the interface after version 1.0, existing users will have to relearn it, frustrating them and encouraging them to consider competing programs.

Designing before coding can have a huge impact on usability (especially if there is good requirements gathering and user research), but practically, it just doesn’t usually happen that way in open source. Almost all software is in the middle of an iterative development cycle, and few projects take periodic “breaks” to reassess requirements, goals, and workflows. Wireframing and mockups of whole UIs are a good planning tool I encourage everyone to do, it’s just that the opportunity to make use of these tools doesn’t occur very often. Some things you can do in the middle of a development cycle are annotated screenshots or mockups of single screens. They take less time than formally documenting the entire UI but get the same point across.

6. Too many cooks. In the absence of dedicated designers, many contributors to a project try to contribute to human interface design, regardless of how much they know about the subject. And multiple designers leads to inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.

This signal:noise problem also prevents good ideas from emerging and scares away potential design contributors. It also makes establishing those important developer-designer relationships harder by making developers more wary of any “design experts”. As a result, common communication mediums such as mailing lists become useless. However, discussion on usability and UI design has seemed to moved to blogs. Currently the level of effort is high enough to reduce some of the noise, but in some ways discussions can get even more diluted and off track.

7. Chasing tail-lights. In the absence of a definite design of their own, many developers assume that whatever Microsoft or Apple have done is good design. Sometimes it is, but sometimes it isn’t. In imitating their designs, Free Software developers repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.

I completely agree with this one. I can’t remember how many times the argument “Windows/OSX does it this way so it must be correct” was used to justify a design. Just because they make money from selling their software doesn’t mean they did things the right way. Just because users are used to it doesn’t mean they can’t or won’t learn a better way. There is also a danger of reusing patterns, especially if the patterns aren’t that good to begin with.

8. Scratching their own itch. Volunteer developers work on projects and features they are interested in, which usually means software that they are going to use themselves. Being software developers, they’re also power users. So software that’s supposed to be for general use ends up overly geeky and complicated. And features needed more by new or non-technical users — such as parental controls, a setup assistant, or the ability to import settings from competing software — may be neglected or not implemented at all.

I doubt MPT was ordering in terms of priority, but I would reorder this to near the top of the list. Open source began as a software movement for developers by developers. The primary users were traditionally developers, but over time open source software grew in popularity, attracting a diverse population of users beyond developers. When new users who were less technically savvy began using developer-centered software, it became the tipping point at which open source software went from having an “advanced user interface” to a “bad user interface”. These users didn’t have the same domain knowledge, skills, or patience as the developers who created it. Users suddenly became essential participants in open source software development because it is often their bugs and wishes which drive future features and functionality.

Now the problem is that developers are still coding for themselves and not the hordes of other users. Or they try to code for the other users but don’t understand them well enough to sufficiently solve the problem for them. This is why user research is so important. It arms developers with knowledge of their users so they can code for themselves and other users and make everyone happy.

9. Leaving little things broken. Many of the small details that improve a program’s interface are not exciting or satisfying to work on. Details like setting a window’s most appropriate size and position the first time it opens, focusing the appropriate control by default when a window opens, fine-tuning error messages and other text to be more helpful, or making a progress bar more accurately reflect overall progress. Because these things aren’t exciting or satisfying, often years go by before they get fixed. This gives users a general impression of poor design, and that may in turn discourage usability specialists from contributing.

MPT makes an excellent recommendation of scheduling n time or resources for UI and usability issues per release. This is a pet peeve of mine which is usually irritated more by industry than by open source. I find it hard to an hour long meeting to explain to a development team why they should make a single simple change when it would have taken them an hour to make the fix to start with. The problem is often prioritizing usability as a requirement than a feature. Bad usability is a bug. A bad label is bad usability. A bad label is a bug. Fix bug. Fix usability.

10. Placating people with options. In any software project with multiple contributors, sometimes they will disagree on a design issue. Where the contributors are employees, usually they’ll continue work even if they disagree with the design. But with volunteers, it’s much more likely that the project maintainer will agree to placate a contributor by adding a configuration setting for the behavior in question. The number, obscurity, and triviality of such preferences ends up confusing ordinary users, while everyone is penalized by the resulting bloat and reduced thoroughness of testing…

MPT recommends a “strong project maintainer and a culture of simplicity”, but simplicity doesn’t necessary solve problems. The goal is to understand the problem you are trying to solve. Sometimes that can be done by adding a function, sometimes that can be done by changing a function, and sometimes it can be done by removing a function. Again, with my User Research stick *bop*. The real issue here is that a project doesn’t have a shared vision or understanding or agreement of who their primary users are. As a result, you try to please everyone instead of who you ought to. The loudest voices are not always the majority. They’re just the loudest.

11. Fifteen pixels of fame. When a volunteer adds a new feature to a popular application, it is understandable for them to want recognition for that change — to be able to point to something in the interface and say “I did that”. Sometimes this results in new options or menu items for things that should really have no extra interface. Conversely, removing confusing or unhelpful features may draw the ire of the programmers who first developed them.

Hmm, happily I don’t think I’ve ever experienced this one :)

12. Design is high-bandwidth, the Net is low-bandwidth. Volunteer software projects are usually highly distributed, with contributors in different cities or even different continents… Solution: Develop and promote VoIP, video chat, virtual whiteboard, sketching, and animation software that allows easier communication of design ideas over the Internet. And whenever possible, hold physical meetings for developers to collaborate in person.

This does not apply only to design. Developers also benefit from richer communication mediums. You may be surprised how well some designers can work with other people over the internet, especially in the current constultant-culture the industry is supporting.

13. Release early, release often, get stuck. The common practice of “release early, release often” can cause poor design to accumulate. When a pre-release version behaves a particular way, and testers get used to it behaving that way, they will naturally complain when a later pre-release version behaves differently — even if the new behavior is better overall. This can discourage programmers from improving the interface, and can contribute to the increase in weird configuration settings.

This point I disagree with. The beauty of open source software is because it is so iterative. Releasing early allows you to try new ideas and test design assumptions. When the bugs start rolling in, you’re not stuck until the next major release — you can immediately make adjustments and re-release. It is becoming a more common practice in industry to promote small changes over time than to put all of your changes in to one release. Users have an easier time adjusting incrementally than having to relearn a new UI. And many open source projects move so fast — there are good chances that your early adopters catch bugs and UI issues before the more sensitive users ever see it. By the time the rest of the world updates, a lot of things are already fixed.

14. Mediocrity through modularity. Free software hackers prize code reuse. Often they talk of writing code to perform a function, so that other programmers can write a “front end” (or multiple alternative “front ends”) to let humans actually use it. They consider it important to be able to swap out any layer of the system in favor of alternative implementations… This is good for the long-term health of a system, because it avoids relying on any single component. But it also leads to a lack of integration which lessens usability, especially if the interfaces between the layers weren’t designed with usability in mind.

I think code reuse has helped maintain consistency, at least in KDE. Its when there isn’t a class or component for a UI pattern or element that we run in to usability issues because you have 10 developers designing the same thing in 10 different ways. When you go to fix that usability issue, it has to be fixed in 10 places. The benefit of classes and components is if you fix it in one place, the changes cascade through the rest of the environment, or developers have sample code they can use to easily replace the old code.

15. Gated development communities. When you do anything on a computer system you are relying on software from several different development teams… [Often] these teams don’t communicate with each other frequently. And unlike their proprietary competitors, they nearly all have different release cycles. This makes usability improvements difficult and slow to implement, if those improvements involve coordinating changes across multiple parts of the system.

This is a problem with open source development in general. Sure, it effects usability, but it also effects bugs and features. I don’t think it has a direct relationship.

My Thoughts

I believe there are three areas which effect open source usability:

1. Education: Knowledge of and understanding of usability and design practices
2. Community: Cultural climate for non-developers to contribute and a community-wide presence
3. Resources: Knowledgeable contributors

Most, if not all, of MPT’s issues could be categorized in to one of those areas. If we can focus on solving the weaknesses in these bigger organizational-level areas than we will be taking much larger steps towards solving usability problems in open source than focusing on individual processes and practices. I have a few ideas on how to reshape the KDE Usability Project based on these three that I will talk about more at Akademy.

More Resources:

• OpenUsability
• FLOSS Usability
• KDE Usability
• Open HCI. Interfaces Magazine, British HCI Group (PDF)
• Debating the Nature of HCI. Interfaces Magazine, British HCI Group (PDF)
• Free At Last: Open Source, A Primer. Interactions Magazine, ACM CHI
• Usability in Open Source. UPA Voice, Usability Professionals Association

seele :: Aug.04.2008 :: General, Open Source, Usability :: 16 Comments »

The KDE Usability Project will be hosting an HCI Workshop during the 2008 Akademy. The workshop will take place on Wednesday, August 13. There will be many sessions covering all types of HCI topics as well as an interactive workshop at the end of the day.

Agenda:

Welcome to KDE HCI Day
Lead by Celeste Lyn Paul and Ellen Reitmayr
A welcome to KDE HCI Day and review of the day’s activities.

Design Research Methods
Lead by Celeste Lyn Paul
Usability is not just about testing. There are all types of research methods designers use to create usable interfaces, some that include participation by users and others that do not. In this session, we will review the different type of research activities and how the results feed back in to design and development. There will also be an opportunity to ask questions to find out which research activities are right for your project.

User Groups and Personas
Lead by Ellen Reitmayr
Lack of user research is one of the primary reasons usability in open source software is so hard to achieve. Learn about the importance of defining user groups and creating personas and how it can improve your project’s usability by helping developers understand their users. After a short introduction on user groups and personas, this session will be a hands-on activity where developers can ask questions specific to their projects and users and get help creating user groups and personas for use in their project’s KDE User Research Profile.

HCI Concepts of the Plasma Desktop
Lead by Aaron Seigo
This session will talk about current HCI issues and future goals of the Plasma Desktop, including discussion on interaction concepts such as zooming user interfaces (ZUIs), passive configuration, and direct manipulation, as well Plasma and its use across the device spectrum.

KDE4 Human Interface Guidelines
Lead by KDE Usability Project Members and Season of Usability Interns
During the past summer, 2 Season of Usability interns helped us create patterns and guidelines for the KDE4 Human Interface Guidelines. In this session we will review notable changes between KDE3 and KDE4, review new guidelines and patterns, and discuss samples of HIG violations and their fixes. A question and answer session will follow for developers to ask specific questions about the guidelines and how they might apply to UI problems they are working on. More involved questions or design problems may be discussed during the KDE4 Open UI Workshop.

KDE4 Open UI Workshop
Lead by KDE Usability Project Members
This is an open discussion period for KDE4 HIG- and UI-related issues. Developers should come prepared with questions and sample screenshots (website links or USB key) to discuss and get assistance. Benefit from other developers’ questions and participate in the discussion.

seele :: Aug.01.2008 :: General, KDE/Kubuntu, Usability :: 2 Comments »

One of the interesting things I learned at the last Ubuntu Developer Summit was the widespread use of implicit save in the GNOME environment.

Implicit Save (or can also be called instant apply or instant editing) is when changes made by the user are automatically saved by the system without the need of the user confirming the changes by performing a Save or Apply action (implied to be so by the action of the user making the change). Explicit Save is when the user explicitly confirms the change by performing a Save or Apply action.

In many cases, implicit save makes a lot of sense and makes the configuration and interaction with options much more natural. For example, consider (Ubuntu) GNOME’s Appearance Preferences dialogs. The widget theme selected is the current theme. Select a different theme and it is changed immediately and automatically:

The immediate apply is pretty neat, but there are a few things that have me worried. There is no obvious “out” for the user. If you are trying out themes and want to go back to your original one, you have to remember which theme was selected. Otherwise you’re stuck. (I’ve been told that clicking the X button in the window decorations instead of Close will reset your options, but this doesn’t work in the Appearance Preferences nor the Internet Proxy dialogs).

This safety net may not matter so much for changing window decorations or fonts, but it matters a lot when you are configuring more important system-level settings such as Internet proxies. Say a user is exploring network options and comes across the Internet Proxy configuration dialog. They click on a few options to configure a proxy but change their mind. The Close button in the dialog is a bit ambiguous and doesn’t give a hint as to if it will save the new options or not, so the user clicks the X close button on the window decoration thinking it is the same thing as Cancel. Now their network settings are messed up. When the user begins having network trouble, it is unlikely they will remember they reconfigured their proxy information because they think they cancelled the changes.

Look at how KDE handles changes in System Settings. Although the dialogs aren’t as well designed (we’re working on that), guessing the result of a user’s actions is much more clear, and an “out” option is provided to users who may have forgotten they made changes while they were browsing the dialog:

The problem with the current GNOME implementation is that it doesn’t support users who make errors. There are many reasons why a user could make an error when configuring a dialog, but the types of errors which would result directly from the dialog design (i.e. not user knowledge errors) would be attention-based: forgetfulness, interruptions, multi-tasking, etc. Also, users tend to “start over” when a task becomes too complicated or they think they’ve made a mistake. You can’t do that with these dialogs. Also, almost all of the dialogs use implicit save instead of selectively where it makes sense.

Although many long-term GNOME users may have adjusted they way they work with dialogs because of this behavior, your KDE and Windows users are going to suffer. OS X is selective about when it uses implicit save — when it makes sense, and provides revert/apply options for particularly sensitive options.

However, there are a two easy fixes alleviate some of these problems:

• Change Close to OK. Close is neutral and wont help the user when they’re not sure what will happen. In GNOME, Close has a bit of a negative twist to it because of the orange X icon associated with the button. OK is positive and when you click it, is like saying “I am OK with the information in this dialog”.
• Add a Revert or Undo button so users can get back to the original state of the dialog information if they need to start over
• Optionally, I would also change the window close button (X) to be a Cancel function instead of the current Close (OK) function. Users resort to controlling the window instead of the dialog when they are in doubt and don’t want to save their work.

As I’ve been discussing, implicit save isn’t something we really do in KDE, but it does get used in a few places. Here are two good applications of implicit save in KDE:

KNotes. When you create a new KNote, new notes are saved automatically as well as any text changes so if you close the note and reopen it, all of your changes are there. There is no need to explicitly save every text edit and since the information is very ephemeral, there is no need for a history of changes. Undo is supported.

Konqueror. The bookmark editor is updated automatically and there is no need to explicitly save your changes. Although the interface does not confirm destructive actions such as deleting a bookmark, it does support Undo and Redo actions so you can recover a bookmark you might have accidentally selected.

In summary, here are some pros and cons I can think of involving the use of implicit save.

Pros

• Makes sense in certain information contexts, especially when dealing with ephemeral data
• Supports tasked-based workflows more naturally without the need for supportive interaction procedures
• Easy to adapt to or relearn in cases where explicit save was previously used

Cons

• Isn’t appropriate for many types of information tasks which makes creating guidelines for use and implementation difficult
• Difficult to manage and easily abused since good guidelines would be difficult to write
• Can be destructive and hard to recover from; in many cases and will increase the number of user errors (lost data or unstable system)

I’m interested to hear what the KDE community’s thoughts are on this. Is implicit save something we should be investigating? I think it’s use in Plasma could be valuable, but this is not something I would recommend for configuration dialogs.

seele :: Jul.28.2008 :: Design, General :: 44 Comments »

Although I didn’t get around to reviewing all of the KDE User Research Profiles this weekend, I did spend some time collecting and rewriting some notes I had for the KDE4 HIG and doing an expert review on KNetworkManager 0.7.

KNetworkManager had a few UI changes as well as some old usability problems. The expert review contains comments about these issues, how to fix them, some mockups of my recommendations and other UI changes I think will improve KNetworkManager. None of the recommendations involved a huge level of redesign, but I’m always unsure of what the coding level of effort is for things like this. Surprisingly I didn’t know what every option in the menu did, and so I made some assumptions while doing the review (noted in the document). Comments and questions are welcome.

Expert Review of KNetworkManager 0.7 (PDF 867KB), July 20 2008

seele :: Jul.20.2008 :: General, KDE/Kubuntu, Usability :: 39 Comments »