Archives for posts with tag: web

KOffice Web Presence Strategy Thumbnail (click!)

Things are in the move it seems and I am still all about drafting concepts for a renewal of the KOffice web presence. We have been discussing this on IRC a bit and it seems that quite some people liked the ideas, so I chose to present them here to give others the opportunity to think about it and maybe reuse it or make smart™ suggestions. ;)

From simple to complex

My starting point was to find a solution to present KOffice independently without doubling maintenance work and spreading ressources even further on the net.

At the moment, everything KOffice is quite confusing: there is a terribly outdated (content wise) website that is pretty complicated to keep up to date with the use of SVN, a wiki that is hard to find and needs to be searched for everything and resources both on userbase and techbase. So we have actually four places where content is spread and that need maintenance. Not too clever, ey?

Now we have to start sorting things again.

I would like to see everything that feels like promotion on a landing page on koffice.org, this includes a generally introductory text about KOffice, a description of the single apps, the vision and maybe the KOffice team. Adding to that should be Latest news such as release notes and – in a prominent place – links to external ressources for both users and developers.

Outsourcing

That leads me to my next point: userbase and techbase. Those are highly useful and visible places and should host all the content that is likely to change frequently like tutorials, FAQs and other documentation. By moving content there, we make use of the already existing infrastructure and take quite some work away from the KOffice team to those maintaining the *base sites. Chances are good that this leads to better results and that we provide good tools for community interaction and user created content. Additionally, content becomes easier to find for those who already are familiar with the KDE infrastructure. But providing links on both ends will be mandatory and take make sure, nobody gets lost on the way.

Everything that is only useful to those who actually are closely involved to KOffice development – TODO lists, release schedules, internal discussions and general organisation – will stay on the current wiki. The developers seem to be happy with it and I don’t see a reason to move any of this content anywhere else. There is a enough to move around without this…

Now we only need to write fancy PR texts for the landing page and start moving and sorting content. *cough*

Lifestream

This will add some extra coolness to the whole concept and will be covered later when we have discussed things further. Stay tuned.

There has been some reflections going on about the use of the so called social web after our BoFs at Akademy this summer. I came across some difficulties during the last days though.

Hasn’t the web been social all the time?

In the early days, when I first came across the concept of the internet, usegroups and mailing-lists were entirely social. With broader acceptance of the internet itself, things changed to a more presenting approach. Content became statically available on websites and there was usually no way to interact with the owner of a site apart from email-forms.

With all the buzz around a web2.0 built on the concepts of community and interaction between the users, things have changed again back to where the web came from for the average user. Web start-ups and companies now take a huge effort in building a community and turning their online services into a vivid place of exchange and interaction.

How does this whole thing affect me? Why is she writing a blog about it that gets on the planet?

The idea I initially had at Akademy was to use the most known web services for KDE as a whole. This doesn’t really work out due to various reasons. At least not yet.

What I think would work instead is the use of the social web for KDE subprojects such as KOffice where I recently came up with this idea.

We’re preparing the new release and I suggested to create some buzz for it using web2.0 services. While discussing this on IRC or private chat, it occured to me that not everyone saw my intention behind it.

The biggest advantage of those services mentioned above is the possibility to share and interact. What makes KDE stand out from the crowd is the strong liaison to its community and by using the social web we open new ways of participation to nearly everybody.

Aha. And what is it we should do now?

I will take KOffice as an example for my ideas.

First, I would register an account on flickr for screenshots, one on blip.tv (as it seems to have some advantages) for screencasts and one on twitter to which I would feed all developers’ blogs with the help of twitterfeed.

Then I’d create an account on friendfeed and add all of the accounts I set up for KOffice and eventually already existing ones. With the help of this feed service, I’d get all activites on the various services collected in one place and made available via RSS again. The curious now only needs to monitor one single feed to get all the information available on the internet by the KOffice project and its developers.

And why not simply put it on something.kde.org?

Because it’s all about sharing.

By uploading the screenshots to flickr for example we make them available to everybody and allow comments on it, and by posting them to the right group within flickr we get impressive view counts. All services make us address people that might never have heard about KOffice at all (we all know how very often we stumble upon something we were not actually looking for on the net) and let them comment on or share the information.

With friendfeed we take it even further. Everybody with an account there can forward parts of his subscribed feeds to friends or so called rooms and comment. If anybody in your networks is susbcribed to the KOffice feed and commented on a screenshot for example or liked something, you will see that in your feed, (My feed is here, have a look at it if it’s not all clear yet.) With the right use of the technology available we can reach very far.

And: everything collected within theses accounts can easily be embedded into the existing websites.

Where is the but?

Someone will have to take care for the accounts and get material from the developers involved in the project. Only then it will be possible to keep the content fresh and the audience interested. If everybody puts a little effort in this and — for example — makes it a habit to take screenshots of newly implemented features or a polished GUI and then mails it to the account holder, it will keep the workload for everybody on a reasonable level.

And now that you’ve actually made it to the end of this blog: thanks for reading! :)

I would love to hear your thoughts and comments on this and officially open the discussion here.