Technical

Showing your activity: a plasma widget hack

I like activities. However there are a couple gripes I have with its implementation.

The first is how to switch from one activity to another. Apparently there are at least 7 ways to switch activities already, but all of them fail to simultaneously satisfy two criteria: 1) Being accessible via a keyboard shortcut and 2) visually display an activity list during the switch. The closest implementation is Meta-Q, but that doesn’t show an activity list during the switch like KWin’s switcher does, meaning exactly what order you’re flipping through is anybody’s guess. The Activities widget also comes close in providing a very comprehensive view to manage activities.

Luckily, you can combine the two to somewhat solve this problem in a Meta-Q, Meta-(Shift)-Tab, Meta-Q sequence, but it’s clunky and slow.

The second gripe is that it’s very difficult to tell exactly what activity you’re actually currently on. The only place which says so clearly is on a tab on the desktop, and if you’re busy actually using your computer, that tab is going to be hidden most of the time. Another hint might be due to the change of hue underneath your panel if you use a translucent panel with different wallpapers for each activity – but I personally don’t use different wallpapers. The final hint is due to seeing what other windows crop up when you switch activities, but this is slow to process. This isn’t a problem when only switching between two activites, but three and up become an issue.

It’s vital to be able to always see what activity you’re on. After coming back from a 10 minute break, you might start up another app with it being irrelevant to the current activity. Or you might make detours from your current line of work which means you want to quickly switch between several activities, and Meta-Q’s guesswork doesn’t make this efficient at all. It has to be always in front of you, too, not auto-hidden in a separate panel – especially if you’re doing a lot of typing with keyboard shortcuts so you don’t waste time looking at it or having to remember from the last time you opened an activity switcher interface.

Long story short, I got fed up and decided to make a plasma widget for it. Only barely knowing Python and never opened the Qt or KDE/Plasma docs in my life didn’t help, but I was shocked at how easy it was. After a few hours I’d got something both functional as well as somewhat aesthetically-decent.

kde activities plasma widget

Code is available here – download my plasma widget whichactivity. It’s guaranteed to make real programmers cry.

To install, just plasmapkg -i whichactivity.zip. To uninstall, plasmapkg -r whichactivity. Code is in contents/code/whichactivity.py – you might want to change the colours / icon depending on your theme.

Technical

Tech tip #11: How to have animated wallpapers in KDE

I’ve seen many people asking how to have animated wallpapers in KDE. The current options include specialised Plasma Widgets, or the rather limited yet specialised array of animated effects, such as desktop globe, seasonal change, or virus simulations.

Unfortunately there isn’t a native way to accomplish this, but KDE being KDE, there’s always a workaround.

The idea is to use mplayer to play a constantly looping, muted, fullscreen video and tell it to play on all desktops, underneath all apps, and not show up as a window in the taskbar, switcher, or pagers.

Here’s the snippet:

#!/bin/bash
mplayer -fixed-vo -loop 0 -nosound -fs -name 'animbg' /path/to/yourvideo.avi

Save it as whatever.sh file and chmod +x whatever.sh. (not required but useful for convenience)

The -fixed-vo flag prevents reopening a new window every type the -loop 0 flag is called. -nosound and -loop is self explanatory, and -fs is fullscreen. The -name flag allows us to set a specific window class, which will be picked up by a specific KDE window rule we will create.

A quick note here that mplayer also has the -title flag, which we should be able to use to create a KDE window rule for, but it seems as though either mplayer creates the window and only afterwards changes the title, or KDE has a bug, and so the KDE window rule doesn’t match at runtime.

We can then go into System settings -> Window Behaviour -> Window Rules and press “New” to create a new window rule. Set the window class to an exact match as shown below. For more information you can view the KDE Userbase page on window rules.

In the Size & Position tab, check Desktop, and set it to Force All Desktops. In the Arrangement & Access tab, check Keep below, Skip taskbar, Skip pager, and Skip switcher, and set them all to Force Yes. Hit OK, and Apply your settings. For more information you can again see the KDE Userbase page on window attributes.

Tada! Now you have an animated wallpaper! You can set KDE System Settings -> Startup & Shutdown -> Autostart to run your .sh file.

Life & much, much more

GetKDE.org – the workspace, and what’s going on.

Some updates. Both for newcomers to GetKDE.org and those who have seen this project before, see the homepage, the explore page, and then finally, the page I’m writing about.

Homepage has been updated too:

And explore page updated too.

Hope you like it.

I have to apologise for only having the time to work on this very sporadically. Next in the to-do list is the apps page.

Uncategorized

GetKDE.org progress – Discover KDE!

For the impatient, here is a link to the new page, and for those who missed the last post, here is a link to the GetKDE.org homepage. Finally, here is a screenshot of the newly added Explore page:

The homepage of GetKDE is essentially a hub with a teaser. The site structure itself is split into three sections, Software, Community, and Development.

Those completely new to everything KDE will start off in the Software section, via clicking the “Explore how KDE benefits me” option.

It is then important to market only what is relevant to the user – for KDE, this depends a lot on what device you have. KDE’s objective isn’t to convert users to Linux, however happy that makes our inner penguin, but instead to help people enjoy and make the most of their computing experience with KDE Software.

As a result, this is the page they will see. It’s objective is to make it clear what components make up a computer, which are Apps, Workspaces, and Framework. Different components will interest different people, and the availability of components are also limited depending on what the user is using. For example, Windows and Mac users won’t get a Workspace, but will get Apps and Framework. Mobile users get different Workspaces to non-mobile users. And so on.

The reason this initial segregation is so important is for several reasons:

  1. They are introduced to the branding jargon that KDE users, eg Apps, Workspaces, Framework and understand how it fits together
  2. This allows highly specific and targeted marketing in the next stage – no use comparing Kate to GEdit for a Windows user.
  3. Users understand the scope of KDE development that it isn’t just limited to desktops/laptops and are flexible to bend around what people use.

In other related news, the GetKDE.org homepage itself got a bit of a cleanup, which you can check out live via the link here, or in the below screenshot.

That’s it for this post! More to come!

For those particularly interested in this project, progress is tracked via its WIPUP project space.

Uncategorized

What’s up with KDE.org & Hello GetKDE.org

It’s been a while since I last posted about KDE.org, aka the KDE-www war series. It talked about the current KDE.org design, and how to improve it. The series started with target audiences and conversion goals, picked apart and restructured the sitemap, revealed an initial design proposal with clear-cut priorities, and finally analysed the effectiveness of design.

Since then, the KDE-www team has gotten serious about rebuilding KDE.org from the ground up and has started up project neverland. However, I shall now be continuing the work on KDE.org under a new name, GetKDE.org.

You can visit http://GetKDE.org/ right now – feedback is much appreciated.

One of the most important aspects of the redesign is community involvement. GetKDE.org is built publicly online irrespective of the KDE release schedule. This is so that the community is free to visit it any time and provide feedback and leave comments.

There are a few differences between how GetKDE.org is tackling the KDE.org redo and how neverland is tackling it:

  • The Oxygen team is unpredictable. Neverland’s answer to this is to design without employing the blue-coloured KDE, Oxygen, Air, or Plasma-themed elements as part of the basic design- that way, it will still be relevant no matter what KDE looks like. GetKDE.org instead regards Oxygen’s unpredictability as a fault of Oxygen, and does use the three biggest things which make KDE’s brand recognisable as it currently stands: Blue KDE, Oxygen, and Plasma w/ Air.
  • GetKDE.org is documenting its design process outside IRC. GetKDE.org wants to be 100% transparent with the development process, making sure that the community knows what’s being done, why, and can voice their opinions. This means taking things outside the IRC channel, as well as into real life. This is because any change to a significant visual thing representing KDE may mean changing KDE’s brand. This is not something to be taken lightly. This also means that GetKDE.org doesn’t follow the KDE release schedule.
  • GetKDE.org has a much smaller scope. Only pages within KDE.org will be considered rather that neverland’s objective of a one-size-fits-all solution unifying all sites, including wikis, forums, translated versions, etc. This means that a lot of content will be filtered out, but quality should outweigh the quantity.
  • GetKDE.org is following the previously outlined target audiences and goals. Neverland is following a more rapidly developed, iterative design approach, whereas marketing objectives have been laid out from the start in GetKDE.org, and it will follow that.
  • Neverland is the currently heir to KDE.org. Although GetKDE.org will perform exactly the same functions as KDE.org, most of the team are currently working on neverland. As such, GetKDE.org is being branded as an experimental alternative to KDE.org – and will stay that way until either community or statistics prove otherwise. GetKDE.org will not become KDE.org.

Well, I hope you enjoyed it! More will come soon. Just another week until semester is over and then I’m ready for a sprint :) Updates are being dutifully tracked on its WIPUP project.

Uncategorized

The kde-www war: part 4

A brief history lesson. The introduction identifies KDE.org as a wall of text with a pretty frame and explains why there is a problem. Part 1 sets conversion goals on our two target markets. Part 2 restructures the sitemap to make sense. Part 3 dabbles a bit on concluding the design criteria for the homepage, and reveals the homepage.

In this part, we’re going to take a step back to the release of the homepage design from part 3, and talk a little bit about the science and justifications behind the design. Firstly, a quick note that the design was tweaked slightly after part 3, as the tweaked version can be viewed here.

All webdesigns are made up of three vital elements that work together to make a successful design. Keep in mind that these elements should be considered not just in webdesign but also by application developers.

Notice how the criteria outlined in part 3 addressed each of those 3 concerns directly. Now let’s took at how we’ve satisfied the criteria.

Let’s just briefly skim through brand – we have addressed this by emphasizing KDE’s visual identity:

  • The design has blue and white as its primary colours, which are KDE’s primary and secondary colours respectively.
  • Every single environmental visual element (ie – headers, footers, and non-content elements) on the page used visual styles from Plasma’s Air and Oxygen styles.
  • Every single functional visual elements (ie- the content element) on the page used KWin’s Air widget style.
  • All graphical symbology use Oxygen icons, especially to thematically link together concepts across the design.
  • The radical design choice of KDE’s first non-bordered layout corresponds to KDE’s philosophies of “Experience Freedom”, “Be Free” and “Breathe”.
  • The lightened fonts after tweaking now also corresponds to KDE’s aforementioned philosophies.
  • The iconic Kabel font is used for the KDE logo.

Now we can ask ourselves when we ask “What does KDE look like?“, as soon as we lay our eyes on this design, we can firmly answer “Yes. Of course! That is KDE!

Now let’s look at the content. Content should always come before function, as it sets the scene and helps our users understand what they should expect from the page. We start by giving the most important bite-sized factoids: what is new and awesome, for our existing users audience, and what is this KDE anyway? for our new users audience. We do this by giving a large banner to represent the latest news for the existing users, as well as a large, digestible (free from jargon) definition for the new users. What is more important is if we study why we placed the elements exactly where they are. Let’s study the eye-movements as a user scans the webpage – red being spending more time looking at it, and green being quick glances:

Firstly, let’s just jump back to reality. It is important to realise that people do not scan a page top-down, they glance top-down, then return to the top then proceed to zig-zag occasionally. This means that some people might jump from 2-5, instead of 2-3 (ie- visually oriented people). Also, people do not analyse in detail whilst glancing through – they search for vital factoids and discard everything else. These have good and bad implications:

The good – this pattern and step-by-step process to grasp interest is aligned with the goals/roadmap we outlined in part 1 of this series.

The bad – we are heavily relying on the effectiveness of elements 2 and 3 to provide the vital factoids.  These must grasp interest. Element 3 will target the text-orientated people, who will hopefully see:

Notice how we have successfully separated people from product, and are marketing KDE as a community. The user is immediately not looking at “Hey, download powerful software and a new desktop interface!” (akin to “hey, get free animated emoticons now!“), but instead looking at “Hey, I’m the most important person here, and something is happening which involves me. Something to do with powerful software and beautiful desktops, which are lovely keywords which everybody can say ‘yes I want it’ to. What am I missing out on?“. This will bring them to element 5 – to Discover KDE, and start their journey.

For the picture-oriented people, element 2 is our vital grasper. As the design stands now, it is obvious that the eye lingers longer over the left side of the image (put the more beautiful part of the image there, then?) but otherwise the image is completely unenticing and uninformative. It shows a rotated desktop screenshot and that’s it. This is bad. This should be changed. The blurb is useful though, as it not only says there is some sort of release with a really long fancy name (Software Compilation, anybody? 6 syllables?), but also zeroes into the single key features why it is so awesome. However there is clearly work to be done on defining a visual style for the header image.

Finally, let’s look at the function. What the user will want to do on the webpage.

This is a little tricky, as the homepage is a hub, not a content deliverer. It’s function is as a signpost and not an infographic. For this the design’s function is to direct users to the right page, and allow the user to understand the structure of the webpage, so that he knows exactly what to do next and how things are categorised.

We’ve already done a bit of this by piquing new users’ interests with the blurb and having their eye naturally fall onto the “Discover KDE” part. However let’s take this a step further by thematically linking certain keywords on the page through sequencing them in the same way, as well as using visual icons to mark their similarities. This can be seen below:

This helps the user understand the site’s structure, or three main “sections”, and emphasises their importance through repeating the sequence again and again. Thus the “About” and “Give Back” sections are already given less priority as expected given our goals outlined in part 1 as well as our restructuring labels in part 2, without entirely ignoring them.

This also performs a very important function of all design: the ability to give the user the impression that they have freedom to choose a path, that they are in control, but subliminally guiding them through a sequenced, optimum path. The user is presented with – yes – the entire sitemap. They can read through every single link and understand exactly what the page contains, but are still inclined to follow the three set paths for them. Also shown in the tweaked layout is that only the Community column is highlighted whereas other sections are greyed out – this will not be so on the homepage (all will be greyed out) but this helps users understand which section they belong in (other colour visual indicators will be in play later). This achieves the structural segregation that the original redesign was aiming for, without being too intrusive or clunky.

I’m going to stop here. Those were the main points I wanted to talk about to help raise awareness of the importance of design. I hope you enjoyed this series, and I’ve submitted it as a GSoC proposal, so if all goes well, we can start seeing things live soon!

Uncategorized

The kde-www war: part 3

Just a quick history lesson. In the introductory post we highlighted several tell-tale symptoms that KDE.org had a very big usability and design problem. In part 1 of the war, we discussed a back-to-basics question what are we trying to communicate, what are we trying to achieve, and outlined goals for our various target audiences. In part 2 of the war, we started to achieve the goals outlined in part 1 via restructuring the pages and site map in order to distinctly separate between the KDE: The Community and KDE: Software. In this part, we’re going to focus on the home page – the central entrance hub for new members, and how we can use design elements to achieve part 1’s goals, and still cover all of the masses of content that KDE has to showcase in a streamlined manner as in part 2, and even reenforce KDE’s identity in the process.

Now that we know what we want to achieve and the structure of KDE.org, we can start thinking about the layout of the home page. The home page is – obviously – the most important page of the website. It acts as a central hub to link together everything that KDE has to showcase, it acts as the first stop for information for KDE newcomers, it acts as a publicity and news broadcast, it is the link between the various KDE sub-communities and communication channels, and most importantly, in today’s web-centric world, it defines KDE’s visual identity. After much debate, it had to satisfy the following criteria:

  • Embodies KDE’s visual style and branding – ie, the Oxygen, Air, Breathe, and Be Free. It should be a design that when you see it, you say “that looks like KDE”
  • It had to make people get KDE. To understand KDE not as a product and a software suite, but as a community. We want them to share with KDE’s passion. KDE has grown further than just a collection of apps and a desktop interface, and thus we can no longer be so shallow as to market it as such. We must follow our rebranding efforts to separate people from product, and emphasize open-source’s greatest strength – the community. We are a community, not a company. We create passion, not products.
  • It had to showcase our latest and greatest event/release/activities. However we need to showcase it in a way that people understand. Saying “Akademy 2011 is here!” alone doesn’t mean anything. Nor does “KDE 4.6 released – experience freedom”. Let’s change that to have meaning.
  • Clear segmentation between Software, Community and Development sections – to succeed where the current design fails. Let’s not make it a maze.
  • Absolute directions towards the goals we outlined – Goal 1: to become a user of KDE. Goal 2: Say hi and tell us what’s up. Goal 3: would you like to scratch your own itch?
  • Allow the user to understand how the site is structured and what exists without overwhelming them.

For this part of the war, I’m not going to write a wall of text. I’m just going to throw out the design right now, and let it speak for itself.


More to come. Let’s make a change.

Technical

The kde-www war: part 2

Before I begin this (delayed) post, I would like to reemphasize that a sub-agenda for these blog posts is to raise community-awareness about design issues in KDE. The website is certainly not the only area where there are design flaws, and I was very happy to read over my Christmas holiday a couple a blog posts here and here by Aurélien Gâteau about design issues within applications. I hope we can see even more of these :)

In the initial post, we talked about the elephant in the room: the wall of text that is KDE.org. No solutions were presented, but symptoms were outlined. Then, in part 1, we discovered that the wall of text was partially a side effect of a deeper problem within KDE – the structure, or lack of it. We discussed KDE’s marketing objectives, and the corresponding misalignments within KDE’s website. We finished off with outlining the ideal situation in the future. Today, we are going to talk about achieving it.

KDE has a lot to offer. Our goal is to filter down what it offers based on their relevancy to target user groups. So before we start, let’s look at the current state of KDE’s immediate “sitemap” – this is what the visitor is presented when they first look at the site. I’ve divided them into columns that they belong in, and briefly described in bullet-points what each page does.

Yes, that was long.

Too long. In fact, let me break down the issues here:

Too much choice.

This is the biggest problem here. KDE has a lot to talk about, but newcomers don’t want to be slammed with all of that in one go. For websites belonging to smaller services, each navigational item can highlight a different issue without overwhelming the visitor, because each wrap nicely around a single point of focus. KDE has multiple points of focus. Thus, it should only provide navigation items which hit each topic, not sub-topic. Here are two other websites which deal with the same problem very effectively: Mozilla.org and Opera.com. As you can see, Mozilla ignores submenus altogether, and Opera has a very clear breakdown of the topics they deal with. All in all, nobody should ever be presented with 44 navigational choices.

Imbalance in choices.

Not only is too many items in “About KDE” confusing to the user, some areas in the Community section really seem like pagefiller on what doesn’t need to be included, and others are just a massive list of items. In contrast, the Workspaces section only has 3 links – which combined together really fail to deliver what they could potentially deliver. The user is left with a “is that it? Pages upon pages of history and verbose description about KDE’s past, and only a couple screenshots about what it’s like now?“.

Double entries in the navigation.

A big problem here is that the navigation headers themselves are links to a page instead of a plain divider as it is meant to be. For example, the “About KDE” is a link, and “Community”, “Workspaces”, “Applications” etc are also links. Often this results in the page being simply a summary of all of its sub-pages, which means information repeats itself, two pages have to be maintained in the future instead of one, and users get confused of where the “official” source of information on a topic is. The summary often seems half-motivated, just to fill up a page, with the only exception being the Dev. Platform page.

Ambiguity in categorisation.

The most immediate ambiguity that shouts out at me is the “Support” category. I immediately thought “How to Support KDE”, as is the norm on most other sites out there, but it turns out that it is actually “End-user Docs/Help”. Apparently I was not the first to be misguided, as seen by the later-added “Join the Game” link, which is therefore miscategorised. Similarly, a lot of the “Community” which I identified in my part 1 is nonexistent in the Community section, but is instead filled with links about “KDE: The Foundation”. The Workspaces and Applications category is also separated, even though it need not be – as they are often bundled together when presented to the user. The result of this is a half-assed workspaces section of the site which really undersells what we have to offer.

So, what now?

We have to completely reorganise the website, obviously. The new navigation has to:

  • Provide a smaller number of choices
  • Properly categorise navigational items
  • Remove stub pages that are unnecessary
  • Remove “summary” pages that are unnecessary
  • Hide pages that “only those looking for it should find it” (eg: About Free Qt Foundation)
  • Expose more of KDE’s community, (forums/planets/irc/mail lists/social sites/ocs/etc)
  • Guide users through our outlined optimum navigational route which is aligned with our marketing efforts (as identified in part 1)

Now that we have a clear list of goals, I spent a few days brainstorming and designing a new structure along with the kde-www folks. Here’s the finished product:

Less choice, less confusion.

This new structure narrows down the number of items to 29 areas. However, we’ve decided to not immediately present all 29 to the user, instead settling for showing only 4 items, Community, Software, Development and Support, with the About items hidden in the footer (only those searching for those pages should find it, we shouldn’t showcase it). We’ve merged the Workspaces and Applications sections into Software, which essentially is a visual tour through KDE, instead of splitting it up into single, solitary pages. The community section actually does have community links this time, and we’ve narrowed down the Development items to the bare essentials (open for debate, as the -www folk aren’t desktop-devs), as in general the devs know where information is kept. Ideally, the Development section’s objective is to make it easy for new coders to join.

It is a little hard to describe, but many pages have been merged and some even completely removed, and I won’t go into details describing why every choice was made.

Points of focus

I’ve highlighted with a blue square several points of focus, this are in general more important navigational items, as they represent key sub-topics in each section. Later on in the design phase we shall discuss how these can be emaphsised visually.

Aligned with marketing’s optimum navigational route

I’ve made two arrows in the diagram above, one blue and the other red. The blue represents the optimum path for our new users. It starts them off with “We are KDE”, to answer their question “What is KDE?”, then guides them through the Software section, a visual mosiac of pretty colours, screenshots and beautifully presented features to persuade them “Why is KDE awesome and why should I use it?”, finally, we land them at the “Get KDE Software” page, once they’ve said “OK, you’ve had me convinced. Let’s get started”.

The red arrow is slightly more complex, for people who already use KDE. Their landing page is the “Get Involved” page, of which the objective is to answer the question “Where do I fit in?” When answered, we will direct them to one of our many community outlets within the community section and help them start their journey with KDE. Alternatively, should they be interested in joining the technical aspects of KDE, they can learn about the Dev Platform, and get redirected to the Techbase, which should turn them into super geeks in no time.

That’s it for part 2.

Thanks for reading and I hope you’re enjoying this series. There’s still a long way to go, and you can actually keep up to date on it via the WIPUP project here.

Technical

The kde-www war: part 1

In my initial post, I talked about the wall of text. I described some of the symptoms of the wall of text, and proclaimed that kde.org is terrible. I listed some of the basics of cleaning up text, and gathered some information about the “why” of kde.org.

Unfortunately, KDE.org is representative of a very large and vibrant community, and although formatting and eyecandy insertions will come in good time, we have to first understand the site’s structure to make informed decisions before tidying up small details. KDE.org’s wall of text problem is not simply due to a few bad aesthetic choices, but instead a side-effect of a more fundamental problem in KDE-www’s structure.

When I defined the wall of text issue, I described the problem being boiling to the essence of what you’re trying to communicate to the audience, and how to present it. Thus let’s look at what we are trying to communicate to the KDE audience – of which there are essentially two parties:

The uninitiated potential KDE user

The new user is interested in the single question of “What is KDE?“. They will want to understand that KDE is a community, and that its product is KDE SC – of which is a multidimensional beast full of wonders both for end-users and developers. When this has been answered, we want to tell them “Why is KDE right for me?“, and finally when convinced, “How do I start?“.

New users have a very specific workflow, and so we should recognise this, tailor it to them, and remove any potential “sidetracking” factoids.

The existing KDE user

The existing KDE user knows what KDE is and is currently using it, but most importantly, the existing user IS KDE. The rebranding effort was not about changing KDE to KDE SC, but instead about separating product from people. Technically, open-source is simply a business model, but in reality, open-source is a philosophy constructed by people. KDE’s challenge is how to turn one of open-source’s most intangible qualities into an axiom for all users.

So let’s talk a bit about KDE instead of KDE: SC. It has a “magazine” of sorts, the Dot, which gives “official” news on the ongoing events in KDE. It has an active blogosphere by PlanetKDE, which is populated basically by the people behind KDE: SC, which report upcoming features, discussions about KDE-related topics, ongoing physical events, and ongoing virtual events. It has a micro-blogosphere, by buzz.kde, which highlights recent Flickr and Picasa activity, YouTube videos, Tweets, and Dents. KDE’s community also has the Forums, which acts both as discussions, support and brainstorm. There is a multitude of Wikis: Userbase, the by and for users, Techbase, the by and for developers, and Community, used to organise community activities. There is KDE e.V, which does awesome stuff which isn’t publicised enough, and a variety of groups in social networks such as Facebook and Linux.com. Freenode’s network has a collection of IRC channels where KDE enthusiasts hang out. There is a variety of regional communities which all hold their own KDE specific stuff, and an entire of network of community-contributed KDE resources through the OpenDesktop API, and various other KDE connections through the SocialDesktop.

For your convenience, I’ve bolded what is KDE in the above paragraph. KDE-www, being representative of KDE, must stress that this is what KDE is – firstly by presenting in a digestable form the amazing influx of activity from all of those sources, and secondly by making it easy for any KDE user, old or new, to find out where they belong, and how they can add to the community. If you look at KDE-www from this perspective, it’s not hard to come to the conclusion that KDE.org is terrible.

But where do we start?

Given such a complex problem, let’s start by mapping out the ideal routes for each user. Here’s the proposal:

When looking at the chart above, notice how we clearly separate KDE from KDE:SC. I would like to highlight that the two final goals for existing users are not mutually exclusive. You can both contribute to KDE:SC but at the same time contribute to KDE – as long as you communicate your activity.

Now that we have identified the ideal paths for our target audiences, we can start making informed decisions about restructuring KDE.org. But before I get to that in part 2, feel free to add your opinion.

P.S. There is some wrong terminology used when it comes to KDE:SC, it should be referred to as KDE Software, as SC is more of a technical term used to describe a specific subset of packages in KDE Software.

Life & much, much more

WIPUP 24.11.10b released!

For the uninitiated, WIPUP is a way to share, critique, and track projects. Or more specifically, works-in-progresses. Us in the open-source community are constantly working on things, and being open-source, we like to share them.

WIPUP was specifically built and tailored towards sharing works-in-progresses – ranging from a twitter-like update, to a fully formatted document complete with images, videos, and pastebin support. With WIPUP’s new FreeDesktop approved OCS (open collaboration services) REST API, it’s one step closer to turning the advanced Linux desktop into a Social Desktop.

Imagine being able to share what you’re working on immediately from KSnapshot, or finding a "Subscribe to this project" or "Track this developer" in Amarok’s About dialog.

It’s completely free to use and (of course) its entire codebase is open-source.

Check out the release notes, and then try it out if you haven’t already!

Technical

Help KDE.org defeat the wall of text.

Everybody knows that effective design is very important to any succesful interface – be it an application, a website, a product, or a physical structure. There are lots of reasons behind this, but the one I’m going to talk about today is how design combats the most dreaded wall of text, of which KDE.org is a victim.

(Note: if you’re not interested in reading this post, just skip to the last paragraph where you can help give your 0.02 cents)

Somebody famous once said that it’s very easy to write. So easy, in fact, until the problem wasn’t with finding things to write about – it was finding things not to write about. The question was how to write concisely: boiling to the essence of what you’re trying to communicate to the audience, and how to present it.

But why is it so terrible? Despite what literature students tell you, people do not like to read. Ideally information should enter their brains without having to make any concious effort whatsoever. As interfaces are all about sharing maximum functionality with the user without sacrificing usability, knowing how to minimise (or present differently) the use of text is very important. Here are a few points to consider when critiquing – it is by no means complete and is not applicable in all scenarios.

You shouldn’t need explanatory paragraphs in your interface.

If the explanation is about your product, it’s ok to have it, but it shouldn’t be as long as a paragraph. If the explanation is about how to use your interface – that is the ultimate evil. The easiest way to remove these is to find isolate the most relevant element of the interface to which the explanation belongs to, then only make that explanation appear if the user is interested in that single option. Another way is to split up your interface into multiple interfaces to reduce the complexity of the things the user has to absorb in one go.

Don’t have more than 10 items in your main navigation.

Unless you expect a lot of repeat visitors who know exactly what they’re doing, of course. The point is that newcomers don’t like choice. They like the illusion of choice, but it is your job as the designer to secretly guide them through to the optimum “first impression” route. If you want to sell a product, you want them to be intrigued by X, then be introduced to Y, then be amazed by Z. And in that order. If you offer a service, you want to think what your target user’s daily functions are, and make sure those are in your main navigation. The rest, stuff it elsewhere.

Icons help. They really do.

Icons speak for themselves. A red X means more than a “No”. A greyed out X means more than a “Not available”. An “i” in a circle means more than “More information”. You can forego the word “Profile” altogether if you use an icon of a person. Plus, icons make your interface look prettier. If anybody isn’t sure what an icon does, they can just hover over it.

Be careful of how you present dates.

Dates are the easiest way to reduce readability of your interface. When given the date 04/05/06, Americans will read it 5th April 2006, Europeans will read it 4th May 2006, and Chinese/Japanese will read it 6th May 2004. The entire string “04/05/06” looks like code, and your brain has to do an awful lot of deciphering to understand it. It’s often best to give a full string “4th May 2006” if it’s in the archives where dates are important, a “Last Month” if the user is likely to only be interested in relative dates, or “4 May” (omitting the year if possible) if space is tight. The date is rarely the most important piece of information in a system, so hide it somewhere that only interested people would see.

Present your text semantically.

On computer systems it’s easy to think of text as lines with line breaks. Instead, get back to thinking of text blocked into paragraphs, with presenting one point per paragraph. If you have a list, use a list. Of course on the internet CSS makes this easy to do.

Create consistent visual format indicators.

Bolding text is good for emphasis, colour signify more information, italics hint at “quoted” text, font sizes represent importance, and alignment influences the workflow. It’s harder to do this on desktop applications, but still possible.

Over the next few weeks I will slowly document exactly how we can put this into practice through a live sample of KDE’s website. I will analyse each page and document it here. My objective is to not only beautify and improve KDE’s website (not only defeating the wall of text, but also improving it all around), but to also increase awareness about this in all of KDE’s applications.

Before I start, I need to collect some qualitative data from you, the community. Simply leave a comment to this post answering the following question:

Do you use KDE.org? (as in www.kde.org, not any subdomains such as the techbase, userbase, dot, etc)

If yes, was it a one-time “tour” use, or do you go to it regularly? If it’s a one-time, what do you expect kde.org to offer you? If you go to it regularly, what do you check most often?

Cheers, and until next time!

Life & much, much more

Design, photography, and servers.

It’s been a hectic few days. First off, I was pleasantly surprised to read on the KDE dot news that the KPresenter template contest winners were announced. I was very happy to hear that my submission had been chosen for 1st place! Here’s a picture for those too lazy to click.

Secondly, I’ve been learning a little bit more about photography, and so here’s a little preview of one of my photos. I decided to burn-in the Gentoo logo on the bottom right so that it serves as a nicely patriotic wallpaper. It’s a vague enough shape to be mistaken for part of the picture, but recognisable enough to be Gentoo (I don’t like in-your-face logos). You can download a high res version here. Here’s a snapshot for the lazy. Perhaps other Gentoo users might appreciate another wallpaper!

Finally, I’ve purchased myself a basic VPS plan from JohnCompanies – of whom is the parent company of a very commendable company called rsync.net, of whom I’m still very happy with. Although not as cheap (as in, cheap + high quality reviews) as alternatives such as Linode (who offers double the resources at the same price), I went on a gamble that my great technical support experience will transfer over into a similar great experience.

Unfortunately, JohnCompanies does not offer Gentoo on their VPSes, only on their dedicated server packages. After some quick debate, I went for Debian. I shall proceed to migrate a few of my sites to this new server as well as a few of my existing hacked-together serverside toys. If you experience any downtime or shoddiness with any of my sites (blog + email included), it’s probably just due to the migration.

Uncategorized

Application design polish.

Free software is great. Everybody loves free stuff. However there’s one common flaw experienced by a lot of free software – they look ugly.

The reason behind this isn’t because we have too many programmers (yes, we know you never have enough programmers) and have too little artists – no, the problem is a lot more subtle. The real problem is that there is no clear hierachy within the artists. There is no control. There is no clear structure, focus, and branding. The question so many artists fail to ask ourselves as a contributor to free software is – What do we want to communicate?

To illustrate my point, I would like to use Ubuntu as an example. Regardless of your prejudices for the distribution and/or Canonical, they did do something right – they have a brand. They have a clear, recognisable pallette and style – from colourschemes to typefaces. Why don’t you see it for yourself: go and visit Ubuntu.com. Notice the colours. Notice the icon styles. Notice the typography.

Another example of a project taking the steps in the right direction is KDE and their Oxygen iconset + plasma "Air" attempt. However there is still far to go.

However the issue does not lie with such large FOSS projects such as the above mentioned. Instead the real problem lies with smaller software and application created by smaller developer groups. The reason is because these small applications rarely have to worry about problems such as branding – instead they have to focus on creating an elegant application. Design elegance can only rely so far on the design of widgets in the UI toolkit used. The rest is really up to the developer. Allow me to give a quick visual example of Blogilo, a blog client which I’m using to type out this post. Take a look:

The untrained eye would not see any problem with the screenshot – however the application design above screams complexity. There is no elegance. There is no simplicity – no "flow" (a clear step by step separation of functions). A blog client is not a complex application like an IDE. It exists for you to add, edit, and delete blog posts. Nothing more. When stripped down to its basics, a blog client is naught more but a rich text editor with a few extra options. Instead we have frames within frames, accordion panels, tabs, and buttons strewn about. Overkill, in my humble opinion.

Design polish is a very hard topic to separate what is ugly and what isn’t. It’s blends over into many neighbouring topics such as usability, a macro-view of marketing (in this case, Blogilo is part of KDE), and functionality. If you are interested, however, I would like to direct you to this very interesting blog by Troy Sobotka, one of the folks behind Ubuntu, who discusses this in much more clarity and detail than I am capable of.

Uncategorized

Hello 4.5, hello ThoughtScore.

KDE 4.5 is out! (Yes, I am a little late) I was really happy to have contributed just that little bit to this release and hopefully that trend continues. Just wanted to say how much I appreciated this DE and to congratulate and thank everybody for their hard work.

Something else that could be interesting for some is an updated ThoughtScore video I found lying around the other day. You can find the low quality version on WIPUP (I do have a large version but will not host it online). It contains some small changes since the last video and I quite enjoy watching it.

In other news, I got my A Level results today (for those not under the British education system, that’s basically the grades that determine my entrance into university) and I’m exceptionally happy with my results. Any suggestions of stuff to buy to celebrate (recommended food is welcome – and big + useless items that catch my fancy win extra points) are welcome.

Sorry for the lack of blog posts. I am actually doing some stuff which can be seen on WIPUP, and some stuff just aren’t blogworthy enough.

Uncategorized

More do, less talk.

I’ve been a busy little bee these few days – you didn’t think WIPUP’s beta release would slow me down eh? Unfortunately for you folks, I like to strike a balance between doing and talking – sure, more talking and doing doesn’t see any results soon, but more do and less talk is just plain selfish. As such, here’s what’s new in Moult county.

Firstly – the the WIPUP beta aftermath. Could’ve hoped for more users, but I’m happy with how people are picking up on it. So far all feedback has been positive, and we’ve picked up a good few members along the way, some of which have become users. Now that I’ve signed WIPUP up on Google Analytics, we’ve got shorter, sweeter reults:

Because I like looking at the results in percentage increases, I’ll let you make your own conclusions this time.

Meanwhile, a few noticed that this release’s splash was not made by me – rather it was contributed by Nathan from Cetan.ca. This means that if anybody wants to contribute splash artwork, I’d be more than willing to use it – provided that it’s abstract, and that it passes as aesthetically pleasing – and of course credits will be duly given.

The ThoughtScore Project has resumed production – and surprisngly to some – not in any graphical area, but rather in the script. I’ve submitted what I’ve started on it as a WIP available here, and once I implement the “paste revisions” idea for WIPUP suggested here, I’ll allow you to actually write parts of it (well, if you really want to – but no promises on accepting them).

I’ve also been, despite sans internet for 2 days in a wonderful place called Bandung (reaaally beautiful if you go to the right places) I’ve also been busy giving back to the community in KDE. We now have a lovely release counter image (demo’ed below), my submission to their KPresenter template contest, and a little progress on the upcoming release announcement for 4.5. Not to mention I’ve also been in the middle of setting up KDE’s site for development on my localhost to tackle “polish” issues, of which you may see some of my critique here.

KDE Countdown

Of course I’ve still been doing part/fulltime work doing webdevelopment (on my 3rd project now wheyhey), and so if you need any webdevelopering done you know who to poke. Also, being in Indonesia also means I’ve been rockin’ with my relatives.

Come on, a post like this with loads of links definitely means I’ve been busy. Excuse the insightful-informative post tradeoff.