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.

Related posts:

1. The kde-www war: part 4
2. The kde-www war: part 3

This is a walkthrough of my year 1, semester 1 architectural portfolio. There’s a lot of beginner-trash in it of course, but I hope I’ve condensed most of it from the around 150 pages worth of content. (Yes, you read that right – 150. That does seem excessive for a portfolio, but it actually isn’t that much, as they are double sided, and there were actually two portfolios, not one) So think of it as two 25 page portfolios really, plus extra content. Due to the immense quantity of work, I’ve cut out the majority and just focused on a few and will not have time to explain the details of each project.

The work inside was since March, so about 12 weeks worth of work, and the portfolio itself only had a week to create everything.

Note that for those who have been stalking me on WIPUP, some of this won’t be new stuff.

The portfolios were both presented in a stylishly hand-made briefcase. Yes, it is upside-down in the picture above. That briefcase was also the first proper physical object I’ve built before, so I”m quite pleased with how it turned out. An A3 sheet of paper fits very snugly inside.

Upon opening the briefcase, the audience is overwhelmed with tons of gewgaws and knick-knacks of every kind. For one of my courses, we were situated on the imaginary town of Cliffton (which has a landmark cliff, surprise surprise), upon which my building was a kayak manufacturing plant. The portfolio was designed as though a tourist had stumbled through the town and picked up trash along the way.

Looks exciting, eh? Well, let’s toss out the dodgily crafted kayak (needs lots of work) and the business cards with tiny sketches and drawings on them and look further.

The bulk of the portfolios were presented in two hand-bound hardcover books of cropped A3 and A4 sizes respectively. These held the parts which couldn’t be presented in more interesting formats. The A3 cover seems to have bent for some odd reason, perhaps its the glue.

The portfolio design itself was a very minimalist grid layout that some might remember first cropped up in my experimental web-folio user interface. Just smack in the center of the page. Pages were laid out in a “text” on the left, and “image-only” on the right per spread.

The left would always follow the same layout, and slowly build and construct an increasingly complex timeline of events as the person progressed further through the book. I found it a great way to put the work into perspective as well as to make the “text-only” section not so boring.

Some pages, however, with the more interesting technical drawings were complete spreads to-the-edge. The above we see a proposed abstract and conceptual transformation of the “CarriageWorks” site (a rather hip place here in Sydney, recently hosting TEDxSydney).

… as well as full-page renders, of course. People do like eyecandy.

… some of the more diagrammatic pages with thin strips through the page spread …

… and of course the napkin-sketches that show the birth of ideas.

More full-page renders – there is a lot of detail in these renders, which is why I chose the rather bulky pagesize of A3. (I find A3 landscape books rather cumbersome, but it was a necessary evil)

One of my projects involved the insertion of a set of rails and tracks into a back lane such that existing elements could be transformed and reattached into new layouts such that they performed different functions. (This wasn’t for the design course, but rather for the communications aspect, so let’s not look at why people would want to sit on bins and trip over tracks)

It was appropriate to create an IKEA-esque instruction manual (a separately provided A5 handbook) as to how to assemble the product, aptly named Konstruera Bagar. (name chosen by Erik Kylen) It means “Construct Arc”, I am told.

The insides are full of bad Swedish puns, unnecesary Swedish accents, and completely incorrect grammar, but let’s not get into that. It is, of course, also available in 80 different languages.

The design portfolio (the A4 book) favoured a more clean-cut “photos-only” showcase rather than the heavily diagrammatic approach of the communciations portfolio.

… here we see some of the detail in the tilework of the models done during design …

Along with the design book, a small fold-out visitors’ guide to Cliffton map was presented, offering both very scenic views and maps of the surrounding area and context, as well as a charming watercolour rendition of the building on the back – oh, and of course free coupons you can cut out.

My tutor was also invited to the monthly KayakersAnonymous pre-meeting congregation, showcasing the community areas of the building, and the various zonings that changed depending on the time of day.

Here we have the Kayak Maintenance Guide. It is probably important to mention that our imaginary town’s primary transportation system was kayaking through a system of canals. My building was essentially the town garage.

Apart from blabbering on about your warranty, the maintenance guide also details how to service your kayak, as well as exposes the internal processes of the buildings and various circulation paths you can take to minimize further damage to your kayak when coming to the building.

What briefcase would be complete without a newspaper clipping from the “Cliffton Times”, mischieviously dated Nov 11, 1918. It details the proposal of the building as well as the zoning decisions that were made within and outside the building site. It also pokes fun at some of my other group members – why not :)

Finally, two A1 panels of the final presentations from each subject.

Well, I hope that was interesting! I might post a PDF of the documents themselves, but that’s going to have to wait.

No related posts.

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!

Related posts:

1. The kde-www war: part 3

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.

No related posts.

No related posts.

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

No related posts.

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.

No related posts.

There is a demo hosted on WIPUP, so if you’re interested I would appreciate your comments.

Please note that all thumbnails are currently just placeholders for future thumbnails which will be pulled directly from WIPUP.

Sorry for the lack of blog posts, I have been working on quite a few stuff as well as some real life projects. There will be a minor WIPUP release on the 23rd to bring some polish to the system and to fix bugs.

No related posts.

It is a fixed width, fixed height website design. Technically speaking, it’s a rather simple design. Most website frontend coders would just launch right into slicing, but this time I wanted to have some fun. I wanted the freedom that any slicer and designer yearns towards – perfect separation between presentation and content, and complete disregard for browser compatibility.

Yes, if you haven’t already guessed, I built this site with CSS3. The only images I used in the end were the green background image, and the splash screen background image (oh, and the leaf icons for the navigation, but those don’t really count).

Most of the layout was straightforward using things like the new border-radius and box-shadow tags. However the lump in the navigation bar posed some complications. In the end I was able to recreate it using a three-layered solution (via the z-index tag). The first layer held the navigation strip with shadow effects. The second (above first) layer created the lump in the navigation’s shape and shadow. A third layer mimicked the second except with a slightly decreased width, slightly offset at the top and a shadow of the same colour as the background to create a "fading" effect for the shadow on the sides. With position: relative, and offsetting to place them, I managed to recreate the effect pretty darn well, if I might say so myself.

Finally, I used Google’s Font API to choose a more appropriate font, applied text-shadows (with a different colour in my a:hover tags to create a nice glow effect) and stuck it up online for my friend to see. Here’s the result (output via Gecko renderer):

This multi-tab bar is a common webdesign element, so this trick might help other CSS3-yearning developers. Here’s the code for those who are interested. The design works in Firefox, Opera, and Safari. Chrome does not render rounded shadows correctly but otherwise works fine. It fails with IE8 and below. Haven’t tested IE9.

No related posts.

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.

No related posts.