Design Monkey

SparkleShare 0.2 Beta 1 for Linux

Hylke — Sat, 04 Sep 2010 22:52:43 +0000

The first beta release is here!
Also, this time there’s some long overdue documentation on how to get started.

Get it here.

The NEWS file:

0.2-beta1 (Sun Sep 5, 2010):

Hylke: Aside from the usual bug fixes and behind the scenes work I mainly added features that increase productivity in the event logs. Not only does it look a lot prettier, each entry in an event log now has a clickable link for easy access to files. It refreshes automatically on new events as well. The Nautilus plugin now has the “Copy Web Link” context menu item, which makes sharing links a whole lot easier.

SparkleShare 0.2 Alpha 2 for Linux

Hylke — Sat, 14 Aug 2010 18:31:49 +0000

I’m happy to announce the second Alpha release for SparkleShare. Please be aware that this is a development release and therefore should not be used in production environments. Although it’s much better than the previous version, it’s still known to snatch some kittens occasionally. Here’s a list of reported bugs that have been resolved (but many more have been fixed).

Get it here.

The README file has some instruction on how to build and install SparkleShare. If you don’t have a git repository yourself, you can create one on Gitorious or GitHub for free and upload your public key there (these are public repositories, so careful with what you put on there)

If you have questions, feel free to drop by in #sparkleshare on irc.gnome.org.

Bug reports can now go under the ‘sparkleshare‘ component in GNOME Bugzilla.

SparkleShare 0.2 Alpha 1 for Linux

Hylke — Tue, 03 Aug 2010 08:41:53 +0000

There’s now an Alpha version for people that are feeling brave and would like to help out and test SparkleShare. Please be aware that this is a development release and therefore should not be used in production environments. It could crash, destroy your data, computer, eat kittens, and then crash some more.

Get it here.

the README file has some instruction on how to build and install SparkleShare. If you don’t have a git repository yourself, you can create one on Gitorious or GitHub for free and upload your public key there (these are public repositories, so careful with what you put on there)

If you have questions, feel free to drop by in #sparkleshare on irc.gnome.org.

Update:

Bug reports can now go under ‘sparkleshare‘ in GNOME Bugzilla.

Whitespace is important

Hylke — Fri, 09 Jul 2010 18:07:22 +0000

Just stumpled upon this article.

It’s good to get a fresh view from someone outside the community. We can do a lot better. A lot of us look at our desktop every day and get used to bad use of whitespace all over the space or simply don’t have the time to report bugs (I usually see a couple of these issues in every GNOME application).

Whitespace, alignments and add to the satisfaction of using software. It’s like the polish on a sports car. Not only is it nicer to look at, it also increases readability and order in your application, and thus usability.

If you have questions or need help on how to use whitespace in your application, please visit #gnome-design on irc.gnome.org.

SparkleShare goings on

Hylke — Thu, 01 Jul 2010 22:36:21 +0000

Just a little post to keep you up to date on some new features in SparkleShare.

Restoring documents to previous revisions

SparkleShare now has a Nautilus extension so you can revert to earlier revisions of a document. I wrote it in Python, which wasn’t a very nice experience, so if someone could write some bindings/nautilus-mono that would be great!

Restore to previous revisions

SparkleDiff

SparkleDiff is a tool that can be very helpful to designers. It allows you to view different revisions of a file to compare them. Previously there were only text based solutions to do this for Git. The tool relies on Git but it doesn’t have SparkleShare as a hard dependency, so it can be packaged separately if you don’t use SparkleShare but would like to use it as a visual diff tool for images that reside in a Git repository.

Compare revisions easily

Contributions

I will soon put up some bounties with the donations that the project has received to get some more contributors in. Meanwhile, I would like to thank the people that have squashed several bugs, set up a proper build system and translations (in no particular order and I hope I’m not forgetting anyone): Sandy Armstrong, Bertrand Lorentz, Łukasz Jernaś, Oleg Khlystov and Simon Pither

Translations

Also, a translation project has been set up on Transifex. So submitting translations is now much easier!

Twitter

Oh, and don’t forget to follow @sparkleshare on Twitter for all the latest news!

Kittens

Kittens

Announcing SparkleShare

Hylke — Thu, 10 Jun 2010 20:42:12 +0000

I’m very happy to finally being able to announce a little project of mine that i’ve been working for the last couple of weeks whenever i had a spare moment:

What is SparkleShare?

SparkleShare is the result of Project SparklePony. At the Usability Hackfest this year in London, a couple of us OSS designers came to the conclusion that we don’t have a proper collaboration tool. We have been using Dropbox for this for a while. Dropbox has a great user experience, but it has downsides as well: you can’t host your own server; it’s not open source and has some freaky things in its license agreement.

Features

So SparkleShare aims to replace Dropbox for us. There are some resemblances and some differences. SparkleShare creates a SparkleShare folder in your home directory in which you can add different remote folders (these can be on different servers). It has the same DropBox like notification system, one feature that we really liked. It allows you to see what others are doing and take peek, much easier than sending around e-mails, forget attachments and add wrong CCs. The most important thing is that the synchronisation is automatic and happens when you add or edit files.

Technology

SparkleShare is build on Mono, GTK+ and wraps around Git. It aims to integrate with the GNOME Desktop. I’m planning OSX and Windows versions as well (in that order).

There is no release out yet, as I’ve yet to fix some nasty bugs, but my programming skills are quite limited (I’m a designer and scriptkiddie). So this is a…

Call for contributors

Help would be very much appreciated! Any kind of contribution would be great. Translations, bug reports, code, docs, it doesn’t matter. Check out http://www.sparkleshare.org/ for links to the source code on gitorious. Join #sparkleshare on git.gnome.org if you have any questions

Special thanks

…to Jakub Steiner and Lapo Calamandrei for the awesome artwork and website design!

Remove the remove icon?

Hylke — Wed, 14 Apr 2010 20:37:22 +0000

Let’s continue talking about removing things. But now, quite literally. Luca Ferretti and people on #gimp rightfully pointed this issue out.

From left to right in gnome-icon-theme:

edit-delete
list-remove
user-trash

These metaphors have been causing quite a bit of confusion lately. The edit-delete icon is used in Empathy in the accounts list, where it seems like it indicates some kind of status. The user-trash icon is used in a lot of places for removing things. While it uses a waste basket metaphor, in a lot of cases the things that are being removed don’t actually move to a place where they can be recycled. Then there’s list-remove. I think this is the true remove icon.

Are there cases where you remove things that aren’t in a list?

Why do we even have edit-delete?

I’m leaning towards removing edit-delete from the spec and use list-remove instead, and if a remove action moves an item to a place where it can be recycled from, use user-trash.

(the situation gets even more confusing when you take the GTK stock icons into account, where edit-delete is a waste basket, another reason to make the icon naming spec and stock icons consistent in my opinion )

What do you think?

We’re removing icons (again!)

Hylke — Tue, 13 Apr 2010 13:15:11 +0000

It’s been five years since the launch of the Tango project and the icon-naming-spec and I think we have done a tremendous work since then. Just look at some old screenshots of the early GNOME 2.x desktop and compare them with those of today. Thanks to everybody who has been involved!

The style has become so popular that almost all the important Linux software has adopted it. Examples include Firefox, Thunderbird, GIMP, Pidgin, Banshee and loads more.

And since it was designed to fit in, applications following the style don’t look out of place in environments that don’t actually follow the guideline. Just try GIMP on OSX, KDE or Windows today and compare it with pre-Tango.

It’s not just the style. Creating icon themes has become a lot easier since then, and, with the introduction of the Icon Naming Specification on freedesktop.org, all major Linux desktop environments conform to the spec.

However, this is only partly true for GNOME. In order to make desktops and apps, who were all calling for different names for the same things, we also introduced icon-naming-utils to map those icons to the icon-naming-spec names. Utilities that we shouldn’t rely on for too long, but allowed us to get pretty results quickly. A workaround to the problem of applications using a huge variation of icon names for the same metaphor.

Five years later, we still rely on the mapping. KDE has moved on since and is spec compliant, so it doesn’t rely on icon mapping any more. This means that KDE can use GNOME icon themes, but not the other way around.

There are some more disadvantages that we have. Browsing the icon directories is tedious because of all the symbolic links and we cannot guarantee icon metaphors. The icon theme is dynamic in its metaphors while an application can use them statically. For example: An application requiring a star icon requests the “star” name, this is mapped to “favourite” in the theme. But this was done by purely guessing. We do not know that the application wants an actual star icon because it’s a star mapping program or that it’s for rating songs or bookmarking in some form or another.

In light of GNOME 3, and its progress in moving out historical artifacts such as bobono, libglade, hal and others and replacing those with new tools, we think it’s time to finally drop this hacky icon name mapping and go for the real deal instead.

This will have consequences for your application. In GNOME 3, we won’t ship the symbolic links any longer. In addition to that gnome-icon-theme will only cover the icons that are in the naming spec. This means that applications developers that want their application to work well on GNOME 3 need to:

update the icon names by looking them up from the Icon Naming Specification. (See http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html)

ship icons that are outside the Icon Naming Specification in the application package itself.(See http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html)

make sure the application doesn’t choose icon names based on the metaphor an icon may have. Don’t use icon names for other purposes than they’re meant for.

We’d also like to have a discussion on the spec itself. It is not perfect and times have changed. Icon names may have to be added or removed. There will be problems, but we’re positive that these can be solved.

So to all developers maintaining apps for the GNOME platform: please update the icon names as soon as possible! If you need help or have any questions, feel free to drop by in the #tango or #gnome-art IRC channels.

Thanks!

On GNOME and Elegance

Hylke — Sat, 08 Aug 2009 14:23:12 +0000

Let me start by saying this isn’t the subject I planned to blog about. I could’ve posted yet another application mockup, but I ran out of ideas (feel free to send your suggestions for next time). but I thought it would be a good idea to illustrate the goals of GNOME Art Team for GNOME 3 and how you can help to realise them.

At the Gran Canaria Desktop Summit Andreas gave a quick and brief presentation of how we can improve GNOME visually. Yes, there will be a new widget theme, and yes, a new icon theme as well. But that really is only half of the job. You can improve the beauty of an interface by changing the looks of it, but only to an extend. There’s this Dutch saying: “You can give a golden ring to a monkey, but it will still be a monkey” (not saying that all GNOME applications are ugly but you get the point).

There are two very clear examples of this.

Design in GNOME used to be all about icons. There were icons everywhere. On every button, and for every menu entry. Bugs were filed against things that didn’t have an icon. And in lack of availability of icons for very specific actions the wrong metaphors were chosen, or metaphors that were already used for other actions in a different application. It wasn’t rare to have five different actions with the same icon (and it still isn’t actually). Having icons had become a goal itself, though there are only a handful that are recognisable by the user.

Pretty? Yes. Elegant? No.

A few years ago almost everyone was pretty excited by the release of Compiz, the compositing window manager. And suddenly everybody in the OSS community cared about graphics. “Yeah! We’re going to have amazing effects now! Take that Windows and OSX!”. And it’s true, Compiz could do amazing things and was technically superior to its competitors. Your windows would wobble when you moved them and become semi transparent. When you close a window it would now burst into flames or fold up into a paper air plane and fly off. And last but not least you could spin the desktop cube whilst whales were swimming comfortably inside it.

Impressive? Yes. Elegant? No.

As said, elegance in interfaces doesn’t come from funky graphics and pretty widget themes. It comes down to how your interface is laid out. And this is where developers can help. Andy Fitzsimon made a great presentation for last year’s GUADEC that goes into these things. A must read.

In this post I would like to focus on how some of these aspects apply to GNOME desktop as it is now. Some common things that can be easily tackled:

Can you guess where the come from looking at the screenshots?

Not elegant: Padding / framing where it is not needed.
Where to look: Image / document viewers, video players, games.
Solution: Remove the padding / framing, content should touch the window border.

Not elegant: Double lines.
Where to look: Nested widgets.
Solution: Rethink your application’s design.

Not elegant: Frames.
Where to look: Anywhere.
Solution: Whitespace.

Not elegant: Unaligned widgets.
Where to look: Anywhere.
Solution: Check surrounding widgets for points to align to.

Not elegant: Headers like “Options” or “General”.
Where to look: Preference windows.
Solution: Remove them or come up with something better.

Not elegant: A header for only one or two options.
Where to look: Preference windows.
Solution: See if you can use whitespace to group things together.

Not elegant: Double headers.
Where to look: Preference window tabs.
Solution: Remove the second header.

These are all things that may sound pretty obvious and are probably in the GNOME HIG, but it’s good to really focus on these things and know what to look for. There are a lot more things to look for, but only fixing these things will make a great improvement. If you see things like this please open a bug report against the application, because visual inconsistencies are bugs too! Let’s make GNOME elegant! (and just work as well!)

GNOME Voice Recorder

Hylke — Sun, 02 Aug 2009 14:09:06 +0000

Another project that has pretty much lived in the backwaters of the GNOME desktop is gnome-sound-recorder. I figured this neat little app really deserved a refresh, so it can be a helpful tool to more people.

Click to enlarge. You can also find the larger image on the Usability Whiteboard.

As you can see a lot of inspiration came from Cheese. What Cheese really does well is removing the need to interact with the file system directly. A thing that we should encourage more apps to do. Banshee and F-Spot are two other good examples of this.

I sent this idea to the gnome-media maintainer Marc-André Lureau who sounded pretty excited. So I hope this will land into GNOME 2.30 / 3.0.

Nothing is implemented yet so more thoughts and tips are welcome.

Special thanks to Andreas, Cube and Nick for their suggestions.