[texrat]

cleaned/updated 07 July 2010

What is this project about?

The essential point is to help developers understand the importance of feedback (and metadata in general), and from there identify the means of enabling them to incorporate supporting mechanisms in their work.

Now, feedback takes many forms. Rating experiences is one. Voting is another. Gaming achievements are yet one more. So are Twitter retweets. Even developer donations! And many many others. Feedback is very important to creating delightful user experiences.

Right now we are in "discovery mode". That means we are helping you the developer by identifying existing resources and bringing them into a single feedback-oriented wiki page for easy access. I can assure you all that we have put hours and hours into this, time you can better spend coding.

Think of this as Phase 1. Phase 2 will be preaching the gospel of feedback. Every item we document is an existing or potential MeeGo project. And it shouldn't stop with MeeGo-- much of what we are looking at and for belongs to all of the open source world.

So why do we need an open, mobilized feedback ecosystem?

• A mobile Internet is the future (per recent Gartner study)
• We want to be fully engaged in Internet activities
• We are more interested in the opinions of friends than strangers (ratings context)
• Walled garden social networks will stifle the free flow of information and cripple discovery opportunities

How can people contribute?

So here it is in a nutshell: so far this meta-project is mostly idea and theory. That's great for high-level discussion but not so much for presentations, much less making anything real happen!

For those asking what they can do right now, the answer is simple: help us research. I have been Googling my fingers off trying to find references and rationalizations for the identified needs... but I can only read so much. So I'll lay out the process where ANYONE can help:

• Identify an area that interests you, found in this list: http://wiki.meego.com/MeeGo_User_Eng..._Project#Areas
• Research the subject matter. Try to find existing best practices, preferrably open source BUT it can also help to point out successful endeavors in closed source that have no open equivalent (challenge the community!). Independent studies and academic papers can also be very helpful.
• Synthesize your findings, and update where appropriate (see below)
• Communicate your thoughts! Don't be shy!

This forum thread makes a great place to interact. But we're not limited to it! Feel free to take advantage of the following:

• Wiki project page: http://wiki.meego.com/MeeGo_User_Eng...mework_Project
• Wiki project discussion page: http://wiki.meego.com/index.php?titl...edit&redlink=1
• Akademy 2010 whitepaper (yes YOU can edit!): http://docs.google.com/Doc?docid=0AQ...Mjhid2Nm&hl=en
• MeeGo email lists: http://meego.com/community/mailing-lists
• Me! (email or even cell phone)

What next?

As stated earlier, Phase 2 is putting rubber to the road. We will need people to act as conduits to projects like NEPOMUK, Gluon, GeoClue and Silk. In order to create a consistent, engaging user experience we need a degree of metadata harmony across MeeGo coding projects. That's where we come in handy!

Please don't be discouraged by lack of technical details-- those will be filled in much faster by an army than me alone! In the end, I'll take care of editing.

Thanks all!

[texrat]

Lots of views, no Thanks or comments... hopefully that doesn't translate to possibility of success.

On a brighter note Toni Nikkanen has volunteered to act as co-coordinator so that helps. I have been informed that the bulk of my experience being in proprietary tools and environments could hurt credibility, so maybe I'll gradually slide most of it his way.

[fatalsaint]

Fixed . You haz thanks!

I think the ability for bugs/reports to be sent directly from the device is a good idea (user having full control however: No automated "Your app crashed, Im going to send all this data back to the dev for you without your input").

Also, the ability to rate apps (and leave comments) from the device would be gold.

Using the webpage is not as streamlined as simply using the built-in application manager for that.

[texrat]

Originally Posted by fatalsaint

Fixed . You haz thanks!

I think the ability for bugs/reports to be sent directly from the device is a good idea (user having full control however: No automated "Your app crashed, Im going to send all this data back to the dev for you without your input").

Also, the ability to rate apps (and leave comments) from the device would be gold.

Using the webpage is not as streamlined as simply using the built-in application manager for that.

Thanks!

As for automated dump-sends: any silent sends should be pre-approved by the user (not necessarily individually, although that should be an option) and fully configurable. In fact user engagement in the context of this proposal permeates everything.

As for ratings-- the goal is to add ratings metadata to all media types and push the functionality so far upstream that it winds up enabling a vast feedback ecosystem. That's the holy grail of user engagement.

[texrat]

Specific to project management: once I massage the wiki page into better shape, we will start breaking this down into action items. To that end, if you see where you would like to contribute but have not yet added yourself to the team please do so ASAP and explain what you would like to work on. Thanks.

http://wiki.meego.com/MeeGo_User_Eng...mework_Project

[qgil]

This is a cool activity. Thanks for pushing it!

Compared to Maemo, we need to spin it in a slightly different way, based on the MeeGo unstable releases. The MeeGo project (and all its vendors) share a common interest in having as much testing and feedback as possible during the 6 months a MeeGo release is being developed. Then vendors will take that release and create their own products perhaps customizing the UI and offering their own selection of applications (keeping the original MeeGo apps or not).

This project can be of big help promoting the installation and updates of fresh MeeGo releases (or the last stable for the more conservative testers) in compatible hardware. It's from that point where users can start getting involved providing feedback and contributing step by step to their preferred projects or areas.

This project can also be of big help helping the community apps to become more mature and complete, also stepping to "extras-devel" (or whatever equivalent we will have) months before any average $VENDOR device owner will.

In reality the best testing works precisely combining the MeeGo unstable release with the community apps being developed against it. Having real users testing all that is going to be great for the project. And they will have lots of fun (most of the times).

[texrat]

Thanks Quim.

The more I read about KDE's Project Silk [1] the more I am convinced that it makes sense to pool efforts. There is so much synergy between the projects-- and Silk is actually going much farther than I had dared! [2]

My only concern though remains over what little activity there has been lately on the mailing lists [3], and I got no email response from one of the team leads. I have registered for their forum tonight and will start checking it out.

Meanwhile I will take the advice of Knut the Qt Troll and switch from Ubuntu to Kubuntu to get more familiar with KDE. I may even install KDE on one Windows machine. But bottom line, the MUEF team needs to get acquained with libweb [4] as well as other existing resources and identify what gaps remain.

[1] http://techbase.kde.org/Projects/Silk
[2] http://techbase.kde.org/Projects/Sil..._the_user_gets
[3] http://kde.markmail.org/search/?q=kde-silk
[4] http://techbase.kde.org/Projects/Silk#libweb

[texrat]

Quim's comment above made me consider something: we may want to create classes of device-based testing/reporting and tie them to build types. That way different levels of testing could be enabled/disabled per release... so that an RC enables more (or different) test capabilities than a beta which in turn opens up more (or different) than an alpha.

Or use a similar concept for tester classes, where some sign up for (earn?) alpha, beta, RC, etc and again only see testing enabled if the build type matches their preferences/access.

Note that this was just a wild thought and may have no real merit. Feedback and alternatives welcome.

[wjbaird]

Originally Posted by texrat

Thanks Quim.

The more I read about KDE's Project Silk [1] the more I am convinced that it makes sense to pool efforts. There is so much synergy between the projects--

I must admit that after perusing the links about Project Silk, I don't see *that* much synergy with the User Engagement work I've seen you describe. Maybe I just haven't been getting enough sleep lately, but it sounds like Silk is all about providing access to web apps and web pages through a thick client...

Is the idea to use it to wrap bugzilla for bug reporting? That could be interesting, but seems like it only covers a small portion of what you've been talking about.

Are there other synergies you see?

[wjbaird]

Originally Posted by texrat

Quim's comment above made me consider something: we may want to create classes of device-based testing/reporting and tie them to build types.

Makes sense... I think it might be useful to track 3 different categories of release levels - app, os, and device. App and OS should be obvious, but for device, I expect (hope) that we're going to see community ports of meego to many different devices. Depending on how mature the port to a specific device is, the device could be considered alpha, beta, etc...

As an app developer, it tells me useful things to know if a particular issue was reported on an alpha version of my application on a stable OS and device, or a stable version of my app on an alpha OS or device.

And I'm not sure what I'd do with an issue from an alpha app, on an alpha OS, on an alpha device...