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

Tech Tip #9: use Klipper to automatically post to a Pastebin.

I haven’t done a tech tip in a while, but here’s a nice, simple one which I am finding very useful.

Pastebins are a really useful way to share snippets of text. However it’s sometimes a bit cumbersome to have to open a browser window, type in the URL, paste it in, click submit, then copy the URL to share with your friend. That’s why things like wgetpaste exist – small command-line utilities to automate this process and return the URL. wgetpaste isn’t the only one, of course, but they’re all rather similar.

Klipper is KDE’s Clipboard manager – whenever you copy something, via right click -> copy or ctrl-c, it gets added to your clipboard. Klipper allows you to navigate through it – so that you can paste something you copied a while back, or set up custom things to paste, or even – which is what I’ll talk about today – set it to automatically perform an action on the paste. The most common use is to automatically open a link in a browser if you copy a link from somewhere.

What we’ll tackle is to get Klipper to autopaste our clipboard item into a pastebin, and return the URL to us. So just set it up as shown below:

And you’re done! Copy something, press ctrl-alt-r to invoke the actions menu, click “Pastebin”, and now the URL of the pasted item will be in your clipboard for you to ctrl-v to your friend. Neat, eh?

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

WIPUP 22.04.11b released!

WIPUP is a way for you to share your long-term projects and discover the passions of others.

Easter has started, and lots of interesting things are cropping up here and there – one of which is that WIPUP has seen a much-needed update. The last time this happened was way back in November, which is a stunning 5 months ago (yes, that’s almost half a year – doesn’t time fly?).

(Yes, it’s such a cliched and overdone splash screen – click it to read the release notes)

This release, unfortunately, isn’t a big one either. There weren’t any new features added at all, but instead consisted simply of visual polishing here and there to make it a more pleasant system to use and look at.

The reason for such a minor release after all this time is that WIPUP is maturing. WIPUP is aimed at a rather niche group – people who firstly are working on a moderate-to-long-term project. That already cuts out the average joe on the street. Then, that project must be something they are able to, and want to, share. That cuts out the majority of company-funded or commercial projects, as well as every person who is uncomfortable with showing work they think is “bad” and “incomplete”. WIPUP continues to slice away at the market by aiming at those who are comfortable with using a third-party system to host it, rather than their own setup, even though WIPUP is open-source and has an API.

For this niche, it satisfies all of its needs.

This niche – of which the target audience is (rather selfishly) myself.

Yes. You read that right. WIPUP was created for myself. If other people find it useful, then that’s great for them too. But all in all, I created this tool because I needed it. The idea for WIPUP was born by my desire to document the ThoughtScore project – my pet movie – in a more sane way than an increasingly large thread on the BlenderArtists forums. Has it succeeded? Yes. Is it still in use for that? Yes. It’s also used by me to document my work on the KDE.org redesign. It’s also used on my localhost to organise my scraps of work I produce for my architecture course, which will then be compiled into my portfolio.

What is my ambition?

Despite its selfish beginnings, there is a reason WIPUP was made open-source and then added the Open Collaboration Services API. This is because I have an ambition for WIPUP. I want it to be used by the end-users of open-source projects.

People are fascinating. The people who indulge in open-source are even more fascinating, because the average person is passionate enough about a cause like the open-source movement to turn it into their computing life, which is a large element of our lives nowadays. From that, most of you are working on really interesting projects on the side – learning a language, writing a book, composing a song, making a movie. I want WIPUP to exhibit the weird and wonderful of your creations – to emphasise and expose open-source’s greatest strength: the community. I’ve realised that when I threw myself in the wacky world of open-source that I discovered a goldmine of knowledge and passion. I want everybody to realise that too – and be proud of it.

What is your ambition?

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.

Uncategorized

Syncing Kontact with Android

I recently became the proud new owner of an Android phone, or more specifically the Samsung Galaxy S i9000. Upon purchase it was promptly rooted and had a custom rom flashed onto it. Also recently KDE 4.6 was released and after a night of compiling I was sitting at a sparkling new desktop and customising it.

But this post isn’t about KDE 4.6 and nor is it about roms and galaxys. It’s about Kontact 2, part of KDEPIM 4.6 (which is still considered unstable by upstream) and how to achieve the state of PIM-zen which everybody should achieve once in their lives. The state of PIM-zen, for those too lazy to click, is the state where your PIM data (calendar/todo/contacts/feeds/etc) is accessible through any digital medium, be it your desktop’s PIM applications, a website visited from a remote location, or your mobile phone’s bundled PIM-suite.

Syncing your Calendar and events

I’m not going to talk about syncing email, as that has been covered countless times elsewhere. So let’s start with syncing the calendar, as it is the next most prevalent in use. Google phones unsurprisingly sync well to Google accounts – and given that Google accounts have a web-based frontend too, this kills two birds with one stone in our “access everywhere” requirement of PIM-zen. So our solution is going to be Kontact 2 <–Sync–> Google’s PIM Suite <–Sync–> Android device.

Kontact 2 is completely Akonadi based. In comparison to Kontact 1, where there was a makeshift Akonadi-resource wrapper which you could add to harness Akonadi as a data source, Kontact 2 only uses Akonadi-supported sources for your data. Luckily Akonadi makes it easy to connect to data sources, and so there is a specialised Akonadi-GCal-resource which you can add.

To do this, just right click on the bottom left box in Korganizer which holds the calendar sources, click “Add Calendar”, and select “Akonadi Google Calendar Resource”.

To get the resource, you may need to install the akonadi-googledata package. After clicking OK, all that remains is that you enter in your Google username (your email), and your Google account password. It should then start syncing and working flawlessly. Your Android phone can then sync to your Google account’s calendar.

However GCal is very buggy it seems as it isn’t unlikely that you’ll be having problems such as unable to authenticate or unable to grab calendar data. After scouring the web here are a few potential solutions to problems you might have:

  • Add the resource through the Akonadi configuration, not through Korganizer’s Akonadi wizard.
  • Ensure you have suffixed @gmail.com (even if you have an @googlemail.com address) to your username.
  • Make sure you don’t use special characters (non-alphanumeric) in your password.
  • Use the latest version of libgcal (>0.9.3 should be good enough)
  • Remove any older version of libgcal.
  • If you are behind a proxy, set it properly in KDE’s system settings -> Network -> Proxy, if not, ensure it is “Connect to internet directly”. (OpenSuse’s defaults to using env variables)
  • Ensure you have ca-certificates package installed, and the certificate from https://l.google.com/ to the list of accepted certs.
  • Have at least one event in the Google Calendar or it won’t sync (bug).
  • Sign out all other account sessions as detailed here.
  • … and of course, make sure Akonadi is running. (akonadictl start)

If it doesn’t work, you may want to stop akonadiserver, then start it with akonadictl start &> log in order to get a logfile. You can then poke around to see exactly where it failed. #akonadi on freenode may be able to help.

If it still doesn’t work, don’t despair (it didn’t work for me either!), as there is an alternative sync. The alternative uses CalDAV, as opposed to directly using Google’s Data API. To use it, just select “DAV groupware resource” from the wizard from the same screenshot shown above. However when it asks for you to pick the groupware server, click Cancel. This will prompt you to enter the details manually. Now follow the instructions by Google for SunBird for setting up a CalDAV resource, and as shown below in the screenshot, then after pressing OK things should starting syncing fine.

Finally, we should note that there might be some data loss, as Google Calendar doesn’t implement all of the data fields, such as attendees to events. Another thing you might want to note is that exporting your existing KOrganizer calendar into ical/ics and then importing into Google Calendar may not work, as KOrganizer doesn’t follow the ical/ics specs properly. If you are exporting and are manually modifying the ical/ics file such that it works, ensure you define the timezone, otherwise chaos will ensue :D

Syncing your contacts

Android has, just like Calendar, a built-in autosync with your Google account’s contacts. Akonadi also has a Google Contacts resource, which you may use in similar fashion to the Google Calendar resource described above. Unfortunately it doesn’t work with me, and so I’m currently in the process of debugging it with Savago in #akonadi. YMMV, and I don’t know any good alternative to syncing this.

Syncing your todo lists

This is a pain. First off it should be plainly stated that Google’s Android does not have a stock to-do application. Google’s own laughable implementation of a to-do webapp in GMail is – well, I would use the most derogatory adjectives I could think of to describe it, but that would just mislead you into thinking that it is possible to quantify the horribleness of it (which it isn’t) – oh, where was I? Oh yes, Google’s to-do webapp doesn’t allow you to access it via ical or any sane format, is missing a ton of useful meta-tags which some people might want, and so you should probably scratch out trying to sync over Google’s to-do webapp.

The options do you have are limited to what exists on the Android marketplace to read your todo lists. The two major ones are Astrid Tasks and RememberTheMilk, both of which are very good. Let’s cover RTM first.

The biggest downside with RTM is that in order to use the Android application for it (which is very good), you have to be a RTM Pro user, which costs 25$ a year, which is actually worth it if you are really dependent on task lists. Alternatively you could use their mobile barebones webapp which looks ugly but gets the job done. Their main webinterface is probably the only webinterface I actually really enjoy using, but the downside is that you cannot interact with your tasks via KTodo – you get only readonly access via an iCal file (note that you can also use a version where your todo items are converted to events in your iCal file for use through the KOrganizer interface). So the final setup goes somewhat like this RTM Android App <– Push/scheduled syncs –> RTM Website and/or Google Calendar <– Read-only iCal file –> KTodo. It should be noted that RTM supports syncing with your Google Calendar as well, so that’s an added plus if you want to use that interface. Note that there is also a RTM Plasmoid, which just adds icing to the cake.

The alternative is Astrid Tasks. Whilst interfacewise a little more clunky it still does get things done. It can sync with a “space” on the online saas Producteev, which in turn allows you to manage it from there. It also does a two-way sync with Google’s to-do webapp, but is known to be buggy, YMMV. However from there it doesn’t seem to have a way to sync with KTodo. Luckily, in a twisted sort of way, it does allow you to sync to RTM via a now unofficial sync (due to RTM’s policies of not allowing other companies to make added profit from their system), and using RTM you can then do the same sync as above. However if you use Astrid Tasks even with syncing to RTM, you don’t need to be a RTM Pro user and hence everything is free. Your options are therefore Astrid Tasks Android App <–> Producteev/Google, or Astrid Tasks Android App <–> RTM <– Read-only iCal file –> KTodo.

There is a third alternative – GTDAgenda. This webapp closely follows the original principles of Getting Things Done by David Allen. It’s a really powerful tool and comes with both a mobile site and Android application too. The only downside is that they are rather expensive and their free version is rather stripped down. Even when stripped down it does seem a little overkill for my needs, but it might be different for you.

My personal reccomendation is to just go with RTM.

Syncing your RSS feeds

Syncing your RSS feeds are a little tricky now that Akregator’s Google Reader sync is unmaintained and broken. Also Google doesn’t have a stock feeds application (why, oh why, Google, do you leave out the basics!) – update: actually it turns out they have recently published one. This pretty much limits you to running any Android app which syncs with Google Reader (there are a few out there, I personally use Pulse) – or you could just access Google Reader’s mobile application, which is really attractive for a mobile site I must say.

In the meantime, get somebody hacking on Akregator and fix that sync plugin!

… and reach your state of PIM-zen!

I hope that this guide has been helpful to those wanting to achieve that perfect sync across all their devices. Any tips and tricks I missed out please let me know in the comments.

Technical

Toronto’s “mini-sprint”, and Sydney’s KDE/FOSS Community

During the holidays I met up with Eugene Trounev, (aka it-s), one of KDE’s awesome artists to discuss our reorganisation of KDE.org and the design aspects of it (which is coming soon in the series). It was a 2-day meeting and it was my first time meeting another KDE enthusiast face-to-face, as given my inconvenient geographical location in Malaysia I don’t know anybody else here. I won’t post the outcome of the sprint here but it will be released periodically with the rest of my kde-www war series. It was extremely useful and awesome of course (and yes, lots did get done), and since no photos were taken, here is one of a random conifer tree to make up for it:

I’ve just arrived in Sydney, Australia to get ready for my upcoming year of university, and so I wanted to quickly throw out the question to see if anybody in the KDE / Blender / FOSS crowd lives there. If you do, throw me an email/comment and if there isn’t an existing community, let’s start one :D

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!