[maemo-community] Notes from my maemo.org session

[From: Dave Neary]

Hi all,

Apologiesx that I didn't get around to writing these up sooner.

The slides are online and linked in the wiki:
http://www.slideshare.net/nearyd/maemoorg-presentation-presentation

Here are my notes for the presentation:
The goal as stated so far has been "improve maemo.org". But on its own,
that's about as useful a goal as "World peace" - there's no suggestion
of how to get there, what needs improving, milestones to aim for, what
needs to be done to accomplish the goal, and so on. It's like setting a
goal of "Climb everest".

Well, if your goal is something big and vague and hard to get your head
around, the first thing you do is try to figure out how to get in the
general direction. If your goal is to climb everest, and you've trained
to do it, your first step will be to get to Nepal. Then you'll choose
your route, your guides, get to basecamp, make the ascent, and hopefully
get down safely.

The first step when addressing a task as wide as "improve maemo.org" is
to answer the question: who is maemo.org for? What problems are we
solving with the site?

There are a few groups I think we try to cater to (and should streamline
the experience for:

1. Users looking for software for their tablets

A tablet user has heard that there's lots of third party software for
the tablet, and goes looking for it.

2. Developers looking for information and tutorials on writing new
applications or porting existing applications to Maemo

An application developer wants to find information on creating a new
application with Maemo, or on porting an existing desktop application to
Maemo

This covers training information, guides and tutorials, HIG guidelines
for the tablet and porting guides.

3. Enthusiasts (not necessarily developers) looking for a way to help
and get involved

A Maemo Community member is looking for the latest news from around the
world of Maemo, or an interested user wants to know how he can help make
Maemo better

I also include in this people who want to get in touch with the Maemo
community but don't necessarily know how – here's where we can direct
people to IRC, mailing lists, itT, etc.

4. Developers looking for reference documentation

You're an existing developer, and you're stuck into making your
application. You want API documentation, you want it to be searchable.
You want to know how to store config options, how to find out what
signals are exposed over D-Bus by application X or library Y, how to
program the DSP, that type of thing.

5. People interested in the future direction of the project

Not sure if these are covered by other categories - but this would
include people like press, and third parties interested in Maemo, as
well as community members who want to influence the future direction of
the project and would like to have a way to contribute to the roadmap.

6. Users with problems

People come to maemo.org when they have something they can't figure out,
or something which isn't working as it should, to figure out how to make
it work, to get help, to find others with the same issue to share their
pain.

7. People with things to say

maemo.org is not a read-only resource, it is also for Nokia and the
Maemo community to announce what they're working on, to share news and
announcements, and to collaborate together on the platform.


Quim made the observation that these categories can be roughly split
into "those who know what they're looking for" and "those who don't know
what they're looking for". While that might be accurate, I think there's
a big difference between a user looking for software, a non-developer
who wants to help out or otherwise engage the community, and an
application developer learning about the platform.

Quim also suggested that there was a question that we haven't asked,
which should be asked: who are we not going to make happy? It's
important when focussing on use-cases to also state negatives - these
define the scope of the project.


Phase 2: After deciding who we're catering for, and running things
through a filter, we can concentrate on the next question: Given these
use-cases which we should cater to, what content needs changing?

My suggestions:

We need to do is filter what's good from what's not so good – we don't
want to rewrite everything, and official docs and API docs are very high
quality documentation. What we need to do is improve the content that
doesn't currently meet editorial standards, and streamline the site to
make sure that our core use-cases can find where they need to go quickly.

1. Portal pages

There are a number of common entry points to maemo.org – the front page,
the downloads page, the news page... we need to identify these entry
points, and streamline them to allow people to get to where they need to
be quickly. Peter has already worked on improving the Intro section, and
Tim has done some great work on the Community pages.

2. Official documentation structure

When you go looking for official documentation now, you get brought to
pages presenting docs for OS2006, 2007, and 2008.1 – and typically the
2008.1 docs linked to are a PDF rather than HTML.

I think that we need to date articles, but avoid the intermediary step
and link to the latest docs, while providing older docs in a
harder-to-navigate to (but easy to link to) archive of docs.

We need to come up with a link structure that makes sense, and propose
it to the documentation team for feedback and execution.


Quim points out that there are changes in the pipeline for official
docs, and the Nokia team will be working on these in the open, perhaps
making changes here redundant.

I think it's still worthwhile examining if there isn't a way to just
make sure we're pointing to the most appropriate content available,
rather than changing the content we have.

3. Update what needs updating

We can trawl the site, page by page, to decide what content needs
updating, and then get it updated. This mostly applies to the wiki, but
should not be the high priority task. The best way to handle this is
have an "outdated content" bug per page in Bugzilla.

4. Decide what we can throw out

People come to maemo.org when they have something they can't figure out,
or something which isn't working as it should, to figure out how to make
it work, to get help, to find others with the same issue to share their
pain.

5. Integration of ITt, wiki, RSS feeds, ...

Right now, outside sites are clearly different and external to maemo.org
– whether it's the wiki, itT or external documentation, tutorials and so
on. We need to make sure that the best docs available are linked to from
within maemo.org in the most appropriate place. Not sure how to do this
yet...

6. Referencing

For some common Maemo related searches I tried, maemo.org isn't very
well ranked, or old wiki pages with outdated information out-rank the
new wiki pages or updated docs. We need to make sure that, since Google
is the primary way people come to the site, the correct information is
what gets prominently featured and linked to on maemo.org and elsewhere.

Specifically, if you look for "Nokia N810 software download", maemo.org
is nowhere to be found. For "N810 software download" on its own,
maemo.org/downloads is the first hit. Hopefully this is just a case of
modifying page titles and keyword metadata...

Phase 3:

That's a lot of content to change, and I don't think we need to change
it straight away. The next question to ask is not "what are we going to
change?" but "what are we going to change it to?" - what's it going to
look like?

Well, I imagine it'll look pretty, but I'm happy to delegate all design
work on the site.

It should have very little text and fewer links on the portal pages -
these are currently overloaded with content, making it harder for the
user to find what he's looking for.

We should try to have more images to break up content.


Once we put the content changes, which we have broken down into separate
steps, and the style changes & look & feel together, we should have a
dramatically different site, without having changed all the content. And
we will have scaled our everest.

More notes:

Quim suggested, for the front page, something like "What's new?",
"What's cool?", "Get involved" and "Developer forum" for the front page,
pointing to four (new?) portal pages for various use-cases. It's one
idea to bear in mind.

One suggestion re. search results was to allow filtering by section -
only search in downloads, only in the wiki, only in developer docs and
so on.

There was agreement that the first page can be mostly static content
with some dynamic content (but really, sparse) and let people in our
core use-cases get to the content they're looking for in 2 or 3
intuitive clicks (or one intuitive search).

Cheers,
Dave.



-- 
maemo.org docsmaster
Email: dneary at maemo.org
Jabber: bolsh at jabber.org