Monday, October 6, 2008

The Future of KDE's Online Presence?

There is no doubt that KDE has a vibrant online community. Sites such as kde-look.org prove this. People want to interact, share, help, learn and play.

Given this, it makes sense that KDE4 is pushing to provide for many of these online needs. For example, KDE games are getting the ability to play online against other opponents, you can install and share themes and wallpapers from your desktop and you can interact with people using applications such as kopete.

But can we take this further? What is missing?

Well, what about 'learning'? It doesn't take much to realise that much of kde.org and its sub-websites have fallen into a state of disrepair. Much of the information is out of date or obsolete and some websites haven't been updated in years. Also, the system that these sites were built on (Capacity) is not sustainable, scalable or flexible enough to meet the needs of KDE's community. Currently, it is too hard for someone to keep the content up to date. We need to come up with a solid plan for changing this.

What about 'sharing'? We have kde-look.org. From there we can share photos, themes, applications and all kinds of things. It could do with a face-lift and maybe some nice new user features, but it does a good job.

What about 'helping'? How does KDE and its online community enable us to help people? Well, we can file bug reports, get on IRC and fix people's computer problems, we can post on forums and we can become KDE developers.

And 'playing'? Its great to see what the Dev's are doing with KDE games. But can we take this a bit further? Does anyone want to have an online chess tournament or an online pong tournament? Ok, I'd really love an online pong tournament. =D

It occurs to me that there are a few main things that come out of studying this. Number one is - interaction. Everything said above requires interaction at some level. Interaction is a basic human need - we go crazy without it. So it then makes sense for us to concentrate on making interaction as easy as possible.

Here is an example: what if 'Sally' has a problem with Gwenview and wants 'help'? Where does she go? Well, Sally loves KDE, but she doesn't have the first clue about using an IRC channel or filing bugs - she just likes playing songs, viewing pictures and watching movies. Wouldn't it be great if Sally could instantly go to the 'Community Plasmoid' that is on her desktop and have it automatically show her 'nearby' help? Sally could see that 'John Smith' is a KDE 'Gwenview Support' user and Sally can instantly contact him via her (or his) preffered media (IM, video, VoIP, email) and ask for help on her issue. Things like this would make Sally's life so much easier!

At the moment, getting help is a journey. You have to make your way to the IRC channels or journey to the forums and search for an answer. You can also journey to the mail-list and hope for a reply or search the websites and see if you can glean your answer from there. It would occur to me that we need to bring help, in all its forms, to the user - instead of the user searching for the help.

This brings me to the second thing that I think comes out of studying this - intercommunication. If we really want to harness the power of the online KDE community and bring it to our desktops and deliver a truely awesome experience to our users then there needs to be a 'meshing' of the separate online services that we offer.

For example, 'John' is a graphics designer and has created a KDE online account so he can upload photos to kde-look.org to share with others (he uploads them from within Gwenview). John then decides that he would like to help the artists who are working on the next release of KDE. John is approved for svn access and his online KDE account shows this. He doesn't need to create another user login and password for svn. John also decides that he wants to support users who are using DigiKam, so he changes his online KDE account settings to reflect that he is also now a support member and that he supports DigiKam - John states that his preffered method of contact is Instant Messaging or VoIP and his preffered hours of contact are 9am-9pm (GMT+10) - he does all this from the community plasmoid. Instantly, users 'nearby' and all over the world that are having a problem with DigiKam can see on their 'Community Plasmoid' that John is willing to offer help. Fred, who is having an issue getting DigiKam to do what he wants, can now call John through telepathy/decibel and ask for help with his issue.

The biggest thing to note in the above example that neither John or Fred need to leave their desktops to do all this. Sure, there is a server out there somewhere on the intermawebs that is handling all this stuff, but John doesn't need to go and find it, log into it and move around an archaic request->response website to get what he wants done - he does it all from his Community Plasmoid. Application intercommunication.

People shouldn't need to have 10 different accounts with 10 different services to get the most out of the community. They should be able to have one place for their settings and status (with full control over this information) and have this information used wherever they need it, whether it be SVN, mail-lists, Community Plasmoid, kde-look.org, KDE forums, etc.

The next question is, how do you plan on accomplishing this goal? Well, over at the #kde-www IRC channel we're discussing this. We've got people on board who are willing to help overhaul KDE's websites and bring them up to date - but we always need more people. We have plans to switch to a CMS system to make it easier for everyone to help keep content up to date. Also, we are planning to have an IRC meeting soon to further discuss all these issues and opportunities. Anyone that is interested in any of this is most welcome to attend and give their input! =)

Ok. That was a massive brain dump. I hope you can make sense out of it. Let me know your thoughts on this. (I'm tired, so I apologise for mistakes in advance =D )

18 comments:

  1. There is so much more that could be said about 'Open Collaboration'! There is so many processes that we do on our computers that could be enhanced so much by the seamless integration of our online community.

    Of course, it needs to be done right.

    What things can you think of could benefit from this kind of interaction and intercommunication?

    ReplyDelete
  2. I think you're onto something good here. I've been thinking about the benefits that a good integrated website/web services could offer, and they don't even touch some of the areas that you have. I think it would certainly be something worth pursuing in great detail. I wish I had time to say more, but I mostly just wanted to say "yeah, someone else agrees with you, and you're not crazy!" I really wish there was some way to work on such a thing as a paid deal, because I think it's something that warrants at least one person's full attention, if not a small team.

    ReplyDelete
  3. for the account problem:
    maybe OpenID might be a good standard for KDE (websites) to embrace.

    and as all KDE websites use OpenID it is just a matter of time before some nifty KDE app thingies using OpenID emerge.

    ReplyDelete
  4. While I agree that there is much more that can and should be done about online interaction throughout KDE, I think your idea about directly helping each other is flawed. It will lead to a small number of people getting flooded with help requests, all to often posted in a demanding way as if that poster somehow has a right to be helped. You see this on mailinglists all the time. There is a reason that people are expected to do some searching for available answers before asking on a public forum, and that is first to teach them to help themselves, and second (but not less important) to keep the channels usefull and open for everybody. If you switch to a one-on-one model, all help given on this channel will be lost for others, and the presure is onto that one person to come up with a reply. In the mailinglist or forum models, questions are posted for all to see, and anyone who thinks they can help can chip in. At the same time, because the ansers are public as well, this adds to the bank of available online knowledge, because the results are there for others to see (I learn a lot from reading mailinglist threads that I don't participate in!) and search (I find most of the answers to my questions by first searching the archives).

    ReplyDelete
  5. @cies

    While OpenID does seem like a solution, there would still need to be lots of custom information and settings over the top of it. OpenID provides a good basic authentication model, but I don't think it would cater (on its own) for the needs I described above.

    What I'm thinking of would most likely require a far more complex communication of user information, which in turn would require a lot of information to be shared between approved services.

    ReplyDelete
  6. @André

    I actually agree with a lot of what you've said. I think your perception that a small number of people will be inundated with 'help requests' is based on the assumption that there will only be a few people willing to offer help. Of course, this isn't generally true of something like the Ubuntu community. In fact, quite the opposite.

    But the question still stands because the assumption is that it is only one-on-one, that noone else knows that someone is getting help from someone else. Of course, I think it would be great for everyone to be able to see that so-and-so needs help with *insert app* and to be able to be included in the helping process. Also, I don't see any reason why this shouldn't be archivable and searchable for everyone on the interwebs - except when someone needs to go 'off the record' for private issues (such as more sensitive company information or personally identifiable information). This would be an issue with something like VoIP though.

    So yeah, while I recognise that your point is indeed valid - I think we should be building this kind of a service so that what you have raised isn't an issue.

    ReplyDelete
  7. To add to what I just said (more brain dumpage):

    In terms of support, another option is that the user in need of help 'flags' that they need help with *insert app* and then the community is made aware of this immediately and can then contact the person in need of help - still making this all 'archivable' and 'searchable'. =)

    ReplyDelete
  8. "Sites such as kde-look.org prove this."

    Clearly indicates people want to interact. The sites facilitation of that interaction is lacking.

    Concerning techical discussion --

    Stack Overflow

    ReplyDelete
  9. Bravo! Yes, bravo! I look towards such a plasmoid.

    ReplyDelete
  10. Great ideas!

    Could Jabber/XMPP be incorporated into this system somehow? I just had a vision that the support could be a Jabber multi-user chat or maybe several for each topic or application. Following along with the examples, something like gwenview-help@kde.org for instance. The user would connect to the muc from the plasmoid (embedded kopete? :) and all that communication could be logged and displayed in a web page or searchable for the future.

    Obviously you could do something like this with IRC but Jabber seems so much more elegant and provides good foundation for other possibilities like status, privacy and...... GAMES! :)

    ReplyDelete
  11. It sounds a huge undertaking to set up, but the benefit to users would be enormous. The multiple login is definitely one barrier, but getting openid set up is not as transparent as it might be for a new user, so hand-holding on the setup would be needed. At the moment, if you have a kde account you can be linked to it. This needs to be automatic in the sense that everyone using this proposed service needs to have kde-related info stored, so needs a kde account which is instantly active whenever the openid login is active.

    There needs to be obvious and instant access to all sources of information, but users asking for help are already under stress, so don't want to be googling for information on how to set up irc access, for instance. Tutorials such as "Get IRC help set up in 20 seconds" need writing in UserBase, and such tutorials need to be so specific that they can be followed even when the user is afraid that he'll never do anything right again. Never underestimate the brain-dulling effect of fear.

    I love the idea that help requirements could be 'flagged' and that those of us who do user support could follow flags according to our areas of expertise.

    There are some great ideas in this blog. I hope we see them come to fruition.

    ReplyDelete
  12. Please keep your thoughts going. They go really into the right direction. It would help the whole KDE Community and it would be a unique feature that attracts people.

    ReplyDelete
  13. There used to be an awesome open source service called Qunu ( http://qunu.com ). Right now it's been partially revived.

    It works over Jabber/XMPP and the user can either use his/her own Jabber-enabled client or the Django web interface.

    The idea behind it all is that users willing to share their knowledge and help others can tag their accounts with what they know and on which level (i.e. KDE (expert), KOffice (novice), Cooking (average)) and the users in need of help can either browse by tags or search the whole "site" with a question they need answered. Then they get matched with the appropriate "expert" and in a XMPP session they can together solve the problem.

    Qunu even managed at the time to integrate itself into some (FOSS) application — I think Inkscape was one of it. This feature was then accessible from the "Help" menu in the application (e.g. Inkscape) and when selected it would automatically search for the appropriate tags (e.g. "Inkscape") and match the troubled user with an expert.

    Something like this (or even helping Qunu from falling apart) might be a possibility for KDE, I imagine.

    P.S. I hate it that my OpenID provider has gone foo and I cannot remember my Google/Blogger ID :P

    ReplyDelete
  14. Wow, this qunu stuff is amazing. Imagine having a qunu plasmoid on the desktop. We would be half there already. There should be private and official channels with the official ones being followable real-time and searchable as archives.

    I hope qunu gets bigger.

    ReplyDelete
  15. @olingerc: Qunu used to be becoming really big, but then for some reason stagnated just before it reached that peak. The reviving process is going on, but it seems it's undermanned and would need some help.

    Qunu's a really cool solution. It'd be interesting to see if KDE could make use of it. I, myself, would love it! If used appropriately it would be an amazing addition to KDE!

    You can read more about it on their blog:
    http://blog.qunu.com

    About Qunu in practice there's an article I wrote for TUX Magazine (Issue 19). If anyone's interested, but cannot find it, drop me a line and I'll e-mail you a copy of mine.

    ...just my 0.15 € though ;)

    ReplyDelete
  16. Whilst the idea is awesome, having such a plasmoid would be the first step in my opinion.

    The ultimate goal would be context-aware help, the ultimate example would be tooltips. Having online collaboration built in to the applications would be excellent, and Decibel and Plasma's DataEngine and Service abstractions seem to be the way to do this.

    Personally I'm very much a Jabber/XMPP guy, so I would see multi-user chat rooms as the way to go about this, perhaps with a Kopete-based plasmoid and a Plasma containment in the help system.

    Instead of going to the desktop, looking for relevant help, etc. (which can already be done if you replace "desktop" with "Google") the user simply has to click a big, obvious "Help" button, and as well as being presented with the manuals, screenshots, project website, etc. there is also a big button "Get live help with [app name]" which is the plasmoid, already configured with their account and the correct chat room, simply waiting for the user to click it.

    If chat rooms are used perhaps a reply-tracking system could be used, similar to how Gmail arranges emails into conversations by tracking the thread. That would allow anyone willing to help the ability to join the discussion, but would keep simultaneous discussions separate in the UI (only the initiated discussion and its replies would be visible by default, since that's what most users seeking help would want).

    Importantly, keeping the data away from the visualisation should be followed. Putting off potential helpers because they don't like the Plasma interfaces, or the Web interface, or the Kopete interface, or whatever would be a bad thing. That's why using an XMPP backend would be sensible; there would be a plasmoid AND a Web view AND an IM interface AND a mailing list interface, etc. to cater for everyone's tastes without dividing the contributor base.

    ReplyDelete
  17. @Warbo: Pretty much everything you pointed out was implemented in Qunu2 (the current version) ;)

    ReplyDelete
  18. Hi,

    LDAP could be a solution to authenticate all usere on a central system (maybe with single-sign-on).

    Many systems are already able to auth against ldap and there are many bindings too!

    Anyway - good ideas!

    Regards Tony

    ReplyDelete