Design-Boost

I want to assist in the creation of better software user experiences. On a slightly different take, I want to foster the quality and quantity of design efforts and outcomes for and with Open Source / Free Software.

The question of the most effective way to do so, led me to the idea of applying design thinking to how Free Software is being conceived and implemented.

There’s knowledge that many projects could benefit from, that has to be researched and documented. Methods to be developed and shared. Infrastructure to be build. That’s what I will do, and you are invited to join my efforts. Especially if you know a thing or 2 about design, user experience, Erlang, git’s inner workings and web stuff. Extra points for polyglot programmers.

Now, what this is really all about doesn’t fit into a few paragraphs, so bear with me while I elaborate.

Making a difference with Free Software

The current choice of Free Software has much to offer and is the result of much work and dedication by many generous, knowledgeable and skilled people.

But Free Software can and must offer more, and more complete and refined solutions, to fully succeed and fulfill its role in enhancing human lives. Users all around the world should become empowered and enjoy states of flow with minimal interruptions. Lots of little frustrations add up; so do the little victories of successful use. Now think about that being multiplied by millions of users for better known software.

The 4 Software Freedoms are important and can be seen as basis for the best possible user experience, where they do become relevant. But the entire developer, contributor and user experience has to be taken care of. Particularly the freedom to change software has to be be amplified by lowering the barriers to actually doing so, to make a real difference.

Why should you care?

Why should you care about the user experience of others? Because, just like in any social setting and with any kind of common good, we will all be better off, the more people do care. You might feel the altruistic reward of doing something for others, not just yourself. Furthermore, this can be a huge challenge, a test of your intellect, endurance and all the skill you got. What are these good for, if not exercised to their fullest?

User Experience

It might sound like some marketing buzzword, but it stands for the insight, that it’s not a product or service as such, that really matters. What really matters is the experience that is being created. It depends on the specific user and the entire context. We are looking at a system, and some of the components happen to be human.

Because of individual differences and the wide range of possibilities regarding set and setting, generalisations are problematic. They are also necessary due to limited resources and many unknowns. Luckily, quite a bit can be said about a well defined group of people and their environment. Design for more than one individual has to be concerned with ranges, not single data-points, regarding characteristics and abilities.

Humans are emotional and often, on some level, irrational beings. Besides goals and results, there is also the process, the experience of using software, that counts. Destination vs journey. You may speak of the pragmatic and hedonistic qualities of software.

There’s a continuum with result-driven, usually work-related usage on one end, and playing games on the other. For the former, it’s all about effectiveness (being able to do something at all) and then efficiency (low resource use, usually time is most critical). Use of the software is not a goal in itself, in this case. For the latter, it’s all about the how, where the most efficient way may not be the most enjoyable (how this works out is a pretty big subject by itself). What may be loosely described as creativity software, will be somewhere in between. Tools and toys; the categorisation is fluid. Thus satisfaction depends on a different weighting of factors, depending on where a piece of software is seen on this continuum, by individual and case, but likely with clear general tendencies.

The role of design

I don’t want to just highlight the design aspect of creating software, fighting the misconception that design would be limited to making things pretty. I want to make clear that design and software development belong together. That one flows into the other. That no good designer in this realm can stay entirely ignorant of implementation issues, and that no competent programmer can stay out of design.

In the end, it’s all just more or less methodical problem solving. Doing your best to reach specific goals, creating artifacts that have a purpose. It’s just that the most visible aspect of design is concerned with aesthetics. But if done right, surface and guts are closely interrelated.

The current state of affairs

While some progress has been made thanks to tireless advocacy of Usability and Accessibility, there are still widespread misconceptions and questionable practices.

Design by software developers

It seems safe to assume that most Free Software is designed by developers. Not many people are both competent software developers and designers, especially at the same time. Not having the implementation in mind helps to get the UX perspective right. In this sense, it’s not about fixed identification with a vocation, but rather about roles people play in specific projects.

Even just a little insight into UX and design methods should allow developers to make better decisions and to see the value in working with specialists.

There should be a place that presents the most important and effective design knowledge and methods, tailored to developers. It might also work as a general point of entry into the field.

Loud users

User feedback can be great, but some are more loud than representative and paint their needs and assessments as those of a supposed majority. Clear project briefings and defined audiences can help users to choose based on there needs and preferences, allows them to ascertain in how far their feedback may matter to the project and helps project members to decide who and what to listen to.

Half-truths and misconceptions get thrown around. The truth (best current knowledge) should be presented loud and clear. People should feel a cultural expectation of better, more informed conduct.

Noisy discussions

There’s a tendency for every highly visible channel, list or forum to become very noisy, with discussion for the sake of discussion, non sequiturs and even outright flaming. A too high percentage of newcomers, and those persistently ignorant, not just leads to a waste of time, but can also drive away the very people with the desired skills who do or might get stuff done.

It’s no fun having to explain the basics of the field again and again. Especially it’s no fun to argue about what should be given. Everything can and sometimes should be challenged, but only if done in an informed fashion. A well defined and documented set of definitions and required knowledge as basis of discourse should help.

Situational barriers to entry should be as low as possible, but consciously erected barriers to entry can be necessary for certain results. I would consider to apply moderated membership using invitations or applications and questionnaires, reputation systems and comment moderation.

Requests don’t match resources


Inviting users to submit ideas and feature requests can lead to sensible concepts, especially if you encourage differentiation between problems and solutions like Ubuntu Brainstorm does. But in the end, it’s all just noise, if not met with attention, agreement, willingness, competency, time and effort leading to implementation. A better approach would have to include being conscious of these resources.

It should be avoided to fix symptoms, if root causes can be tackled. Building up the courage and ability to change parts of the stack, to work on the architecture should allow to fix issues on the lowest possible level, avoiding duplication and complications. Necessary cross-project cooperation should become more likely and involve less friction with shared planning, research and conception.

Investing work on best practices and infrastructure for the entire life cycle of software could increase the number of people who can and will fix issues.

Path of entry for designers

Designers who want to get involved, have to determine if the ambitions, insight and capabilities of the core developers match the scope of what they deem appropriate or necessary in changes. For fruitful cooperation, it may be necessary to first gain trust in small steps. Opportunities should be more obvious, not require that much research, up-front.

Designers have to rely on developers for implementation. Learning to program to the necessary level of skill may not be feasible. After all, time spent learning to code is time not spent designing and not spent making a living. However, strong frontend/backend separation, GUIs that are dynamic at runtime and authoring environments (perhaps inspired by Smalltalk and Flash) could lower that barrier significantly.

Assessment of competency

From the point of view of developers, it might be difficult to tell in how far (self proclaimed) designers know what they are doing. Some level of scepticism and verification can lead to improvements, as nobody is perfect. But questioning every single decision and detail causes too much friction, at least if done in an unstructured and isolated way.

What if there was a reputation system, designers vouching for the competency of colleagues? Developers recommending designers and designers recommending developers, teams and projects?
Be there or be square

Many design decisions are made on IRC channels, an arcane and scary place for those not initiated. Roadmaps are sometimes drawn on conferences or private meetings. This means you have to be there to make a difference. Further down the road, you get outcomes, but the reasoning stays invisible, as chat sessions will rarely be distilled into concise notes. This removes opportunities for corrections or learning from others.

Any mechanism that would shorten the distance between free-form discussion and concise documentation would be a boon.

Units of design

Textual content, say wiki entries or code, allows fine grained edits as contributions. While there can be small and highly local design issues of similar granularity, design tends to be so much about consistency and an overall strategy, that there seems to be not much room for small and isolated contributions.
Breaking up problems into sub-problems and tasks into sub-tasks can ease collaboration and allow more people to contribute at a lower cost per individual.
If the whole building of reasoning and decisions rooted in a central goal could be brought into a form that might resemble program code, even more opportunities for granular contributions might arise.

Broken chain

Specifications, if used at all, are turned into code manually, risking mistakes in the process. The act of implementing increases insight, but it’s unlikely a separate specification will be kept in sync with changes made at this stage. Runnable specifications would help.

You have to ask what’s wrong with GUI-builders like Glade, if there seems to be a need for separate tools for mockups? The wireframe look should be achievable by using a theme. If a widget layout can be created more efficiently elsewhere, something is wrong. Different expectations regarding precision should be answered by iterative addition of constraints, not by starting from scratch again.

The needs for creating fluid layouts and handling interaction are so similar between creating prototypes, demonstrations, interactive presentations and full-fledged applications, that it should be beneficial to handle all of them within a single approach.

Platform diversity

Increased interest in running applications in the browser and more device form factors and means of interaction in parallel all call for better abstraction between user interfaces and functionality, as far as possible. Software should be more modular and composable. Choice of a ribbon over a classic menu or a commandline should not require a new application from scratch. For every application where it makes sense at all, running it in a browser or locally should require minimal extra effort from developers.

Tackling these challenges will require cooperation between many people and projects. A shared vision, or even a related set of visions should help. Where approaches differ, underlying assumptions, weighting of various aspects, choices between benefits and drawbacks, should be articulated.

Strategy: design design and the software life-cycle

The state of affairs calls for designing the way design shall happen. Optimal results follow from optimal processes. Should you get there otherwise, it’s pure luck.

There should be a clear path from need or idea over design and implementation to distribution, maintenance and continuous improvement.

Much of current software is dominated by a bottom-up approach, with roots in times where hardware offered only a little fraction of today’s capabilities. Doing the best possible job of designing for user needs requires to take a top-down approach, to give proper weigh to human capabilities and limitations. But one also has to be wary of leaky abstractions and take care to stay well within the realm of the technically feasible. Where top-down and bottom-up don’t meet, you need to iterate.

We have code editors and development environments, bugs/feature trackers, Q+A sites … where are the design environments and trackers?

Design thinking and methods turned into infrastructure, with its use evangelised and made highly visible, can change minds and then culture. A few people can only do so much, but an evolved culture will move mountains.

Formal Methods

Just having a clear briefing for every noteworthy software project would be a big step forward. Formal design methods can lead to the following benefits:

  • Avoid oversights and typical errors by working step-by-step and using checklists.
  • Increase width and depth of ideation and conception by working methodically, including the use of patterns.
  • Organize thought, (inter)action and assets to avoid extraneous effort.
  • Have a basis for evaluation, rise above the unsubstantiated thumb up or down level.

The Underlying Goal

Improved software user experiences on a global scale. To get there, do:
Foster quality and quantity of open design efforts and outcomes.

Open design efforts: Design efforts that exhibit openness to the public, collaboration, meritocracy, sharing and permissive licensing.

Permissive Licenses: Licenses applicable to otherwise copyrighted works that at least allow free redistribution and may also allow use for any purpose, creating and distributing derivatives. Examples of permissive license are the GPL and the Creative Commons family (Non-Commercial and No-Derivatives variants are edge cases).

Not just executable Software

Several aspects of such infrastructure won’t have to be specific to designing executable software. Or, from another angle: handling visual and aural design will have to be part of it, anyway. Thus it can be useful for other cultural artifacts, as well. Promoting this should lead to a larger, more diverse and more creative community.

Mission

Create, deploy and maintain a website for managing open design processes and assets.

Where assets are any kind of content wrapped in files such as images, audio and video recordings or compound documents (text and images).

Vision

  • A central hub that supports distributed development. Where design needs meet design competency and solutions.
  • An open design agency, valuing cooperation over competition. Where few people can get much done. Avoiding redundancy.
  • An open design university. A clear path into the field. Where everyone grows wiser.
  • A design showcase. Get to see how it’s done. Learn from analysis and research of others, independent of implementations.
  • A collection of career-furthering portfolios.

Risks and concerns

  • As with most projects: failure to implement, to not reach critical mass …
  • Creating bureaucracy.
  • Duplicating functionality and ending up competing with VCS hosters like Github or aspects of Launchpad.

Early thoughts on architecture

I foresee a website where those with appropriate permissions can edit content immediately and collaboratively. Edits by anyone could be possible, but would only become public after approval (beware of workload and spam issues). All assets, including text, are versioned and can be branched.

I will investigate the use of git as a backend.

Design methods are baked into a set of pre-made project templates. Using a template might be equivalent to branching it, with the later option to stick to one version, or to follow updates.

Credits

Thanks for input, feedback and corrections to:
Kevin Godby
K. Vishnoo Charan Reddy
Troy James Sobotka
Sakari Bergen
Ivanka Majic
Mushon Zer-Aviv

The working title for this was Free Software Meta-Design, but then I thought I shouldn’t appear over-analytical right from start 😉

Advertisements

Backtestground 0.4: Context Extraction Automated

Thanks to a contribution by Sergey Davidoff, there’s now an automated version of extract-background-context with the very inspired and not at all longish name extract-background-context-gnome. 🙂

Provided it’s run from within a GNOME session, it takes care of changing and restoring the desktop background and taking the required screenshots.

If you know how to do the same in other environments, I’m all ears.

Though, even better than all of this would be a low level approach that gets the code responsible to draw all the stuff seen on top of the background to do so for various resolutions and to save that in image files right away.


Flattr this

Backtestground Explained

The following walk-through will explain the idea behind and the use of the 4 command line tools from the Backtestground collection.

Background Contexts

An image that may contain panels, docks, icons and windows, all on a transparent background in place of a wallpaper, is what I call a background context. These can be used to layer them on top of wallpapers, to evaluate wallpapers in another context than your current environment.

Extraction

Create the setup you want regarding what is and isn’t visible on the screen.

Change the background to white. On Ubuntu/GNOME, you can just right-click any empty dektop space and choose Change Desktop Background. Doing so on another workspace allows you to keep the Appearance Preferences window open while maintaining the desired setup on the initial workspace.

Take a screenshot, name it on_white.png. For this guide, lets say you save it in bg_test in your home directory.

Change the background to black, make another screenshot, call it on_black.png.

Edit both screenshots to remove differences such as the mouse pointer (remove it entirely or make sure it’s in the same position) and the time of day (copy that part of the panel from one image to the other).

Open a terminal (Applications: Accessories: Terminal) and enter:
cd bg_test
extract-background-context on_white.png on_black.png

The result will be called context.png.

Context in several resolutions

But what if you need to combine the context with wallpapers in other resolutions?
context-to-common-resolutions context.png

the results will be saved in a new directory context_resolutions. On Ubuntu/GNOME, you can have a quick look with
eog context_resolutions/
and use the arrow keys to move through the images.

Wallpaper in several resolutions

Have a wallpaper and need it in other resolutions, scaled and cropped to the varying aspect ratios?
to-common-resolutions background.png

Results will be saved in a new directory background_resolutions.

This way you can simulate the outcome of the Style: Zoom setting in Appearance Preferences, Background tab on systems running at one of the resolutions (though the interpolation and thus the image quality might be different).

Combinations

Now we have all those separate context and wallpaper images in several resolution, but need them layered:
combine-per-resolution background_resolutions/ context_resolutions/

Results will be saved in a new directory background_resolutions_under_context_resolutions.

Resolutions

to-common-resolutions and context-to-common-resolutions use the same configuration file: ~/.config/backtestground_resolutions (or ~/.backtestground_resolutions, if there’s no .config directory. Executing one of them will create the file if necessary, filled with a list of the 14 default resolutions. Resolutions are specified in width, height order. Formatting doesn’t matter and all text will be ignored.

Backtestground 0.2

I’m happy to announce that I finally wrestled my way through actually making a release with a tarball and a PPA of my extended and improved Backtestground collection of templates and command line tools for designing and evaluating wallpapers 🙂

There are even man pages now, created from docbook xml sources!

UPDATE January 17: Fixed an issue with PPA and tarball that led to incomplete installations (Now it’s actually 0.3)
Ubuntu 10.10 PPA
Tarball

extract-background-context

Expects one screenshot with white, and one with shadow-color (usually black), background as input. Puts out a PNG image with transparent desktop. This is useful for evaluating wallpapers that should go well with panels
and themes other than the one you are currently using.

to-common-resolutions

Expects an image as input and crops/resizes it to several common screen resolutions. The resolutions are now specified in a configuration file.

context-to-common-resolutions

Expects an image with transparent background, that may contain panels, icons and windows (like extract-background-context produces) and crop/resizes it to several common screen resolutions, while doing something hopefully sensible with the content.

combine-per-resolution

Combine pairs of images of matching resolution. Expects 2 paths, either to a single image file, or a directory containing images. Each image found at, or within, the first path will be combined with all images of matching resolution found at, or within, the second path. The first path will be used for the lower layer, the second path for the upper layer, when compositing.

GIMP XCF and Inkscape SVG templates

These are not included in the package, as it’s not possible to install files to the user’s Templates folder that way. The setup script in the tarball does install them, if there is a Templates folder.

Both have a 2560 x 1600 pixel canvas to use the largest commonly offered resolution, currently. Passepartout layers allow to see how things will look when this space is cropped to conform to other common aspect ratios.

This simulates the effect the Style: Zoom setting in Appearance Preferences: Background will have: the image is scaled up or down such that it fills the screen without distorting it. If the aspect ratio of the image is wider than that of the screen, it will be scaled to the same height and the areas on the side will be cropped. If the aspect ratio of the image is taller than that of the screen, it will be scaled to the same width and the areas on top and bottom will be cropped.

For Ubuntu and Gnome users: Putting them into your Templates folder makes them available in Nautilus or on the desktop by right-click, Create Document.

The Inkscape SVG file supports batch export to 14 screen resolutions.

Howto:

  • Bring up the Layers panel (Keyboard shortcut: Shift-Ctrl-L)
  • lock all but the targets layer
  • Select all in the targets layer (Ctrl-A)
  • Bring up the Export Bitmap dialog (Shift-Ctrl-E)
  • Check Batch export 14 selected objects
  • Hit Export

This will create 14 files with names like size_1024x0768.png in the same folder as the opened file. The size_ part is an easy target for a search-and-replace on the SVG file, if you want a specific prefix or target path.

You might want to remove the rectangles in the targets layer matching unwanted resolutions. Repeatedly Alt-clicking allows to cycle through stacked objects in Inkscape (your window manager might be configured to intercept Alt-clicks, though).


Flattr this

Backtestground

Backtestground is a project collecting a few tools to aid in designing wallpapers.

GIMP XCF and Inkscape SVG templates

Both have a 2560 x 1600 pixel canvas to use the largest commonly offered resolution, currently. Passepartout layers allow to see how things will look when this space is cropped to conform to other common aspect ratios.

This simulates the effect the Style: Zoom setting in Appearance Preferences: Background will have: the image is scaled up or down such that it fills the screen without distorting it. If the aspect ratio of the image is wider than that of the screen, it will be scaled to the same height and the areas on the side will be cropped. If the aspect ratio of the image is taller than that of the screen, it will be scaled to the same width and the areas on top and bottom will be cropped.

For Ubuntu and Gnome users: Putting them into your Templates folder makes them available in Nautilus or on the desktop by right-click, Create Document.

The Inkscape SVG file supports batch export to 14 screen resolutions.

Howto:

  • Bring up the Layers panel (Keyboard shortcut: Shift-Ctrl-L)
  • lock all but the targets layer
  • Select all in the targets layer (Ctrl-A)
  • Bring up the Export Bitmap dialog (Shift-Ctrl-E)
  • Check Batch export 14 selected objects
  • Hit Export

This will create 14 files with names like size_1024x0768.png in the same folder as the opened file. The size_ part is an easy target for a search-and-replace on the SVG file, if you want a specific prefix or target path.

You might want to remove the rectangles in the targets layer matching unwanted resolutions. Repeatedly Alt-clicking allows to cycle through stacked objects in Inkscape (your window manager might be configured to intercept Alt-clicks, though).

bgce – Background Context Extractor

bgce command-line tool (Python script). Put it in /usr/local/bin and make sure permissions allow execution.

Expects two screenshots as input:

  • with white desktop background
  • with shadow-color (usually black) desktop background

It creates a PNG image with transparent desktop.

This is useful for evaluating wallpapers that should go well with panels and themes other than the one you are currently using.

Usage:

  • bgce on_white.png on_shadow.png will create a context.png in the working directory.
  • bgce on_white.png on_shadow.png -o some-existing-dir will create context context.png within some-existing-dir
  • bgce on_white.png on_shadow.png -o custom.png will create custom.png instead of context.png
  • bgce on_white.png on_shadow.png -o custom will create custom.png (given that custom is not a directory).

What still needs to be solved: creating such context images for several resolutions without lots of manual work. Maybe some kind of slicing script, taking several separate images and/or some coordinates as input.

sizes

sizes command-line tool (Python script). Put it in /usr/local/bin and make sure permissions allow execution.

Expects an image as input and crops/resizes it to 14 screen resolutions (except the one the image conforms to, if any).

Usage:

  • sizes input.png creates 13 or 14 files with names like 1024x0768.png.
  • sizes input.png -o some-existing-dir will create the files in some-existing-dir.

Currently you have to edit the definition of resolutions in line 50, if you want fewer or different resolutions.

Packaging

Developing these has been fun and straightforward thanks to Python and the Imaging and argparse libraries. Until I looked into installation and packaging. Ran into some interesting issues with setuptools, where I would end up with generated scripts in /usr/local/lib, that would fail because the modules were not in /usr/lib/python2.6/dist-packages/ but
/usr/local/lib/python2.6/dist-packages/. No issue if I just don’t use entry_points. I managed to build a deb after wading trough horrifying amounts of documentation, but I did not manage to build a source deb that I can upload to my PPA. The process fails silently, Launchpad doesn’t tell me what’s wrong. Known issue, filed a support request.

The template files should end up in the users’s Templates folder. Doable with setup.py, even if discouraged. Not possible from a package.

I realise huge amounts of thought and hard work went into all the infrastructure and documentation, so I don’t want to complain too much. But this is why I simply link to a few files that can be used as they are, actually, for now.


Flattr this