Task:Improving maemo.org/Development


[edit] Proposed structure for development portal

This is a proposal for an improved structure for http://maemo.org/development - see the talk page for ongoing discussion related to this content.

There is some discussion on bugzilla at bug #3178: Developer documentation portal needs revision

Different developers coming to maemo.org need four different things - to get started with a Maemo development environment, to get tutorial-type documentation that will help them use it, to consult reference documentation for the platform's APIs, and to get help when they run into problems.

So all of the things in the "Development" section can be split along these lines:

  1. "Getting started" or "Developer downloads" will include:
  2. "Documentation" or "Knowledge base" or whatever we want to call it will include:
  1. "Reference" will include:
  2. "Get help" will include:

The one thing I'm having some trouble with is figuring out where Source code will go (it is after all vital). I suspect that it goes better in a separate section, or in "Developer downloads".

Note that not all of these things will be on the front page - the idea is to provide people with easily identifiable areas where they can find what they're looking for - any content on the portal page should reinforce the meaning of the categories, rather than be exhaustive.

[edit] Other ideas from brainstorm

During the brainstorm, the following points were proposed as priorities:

  1. Place references / howtos / tutorials onto one page so that developer does not need to click through several menus.
  2. Move outdated documentation away, but move older documentation that has not been updated for 4.x up, with a note "not fully applicable for 4.x".
  3. Make it possible for logged-in developers to annotate any place in the documentation. Link to annotations from documentation.
  4. Switch to SB2. SB1 is difficult to install and stays insulated from the rest of developer's system, making development complicated.
  5. Provide an example of simple build environment *not* relying on AutoConf and its friends. A single includable makefile should suffice, when used with SB2.
  6. Clearly *say* in the SB readme that it is not possible to debug every application on the desktop, show how to test applications on the target device using SSH/SCP or some other means.
  7. Maybe provide a few simple stylesheets and JavaScript libs for creating quick iPhone-like web apps running in MicroB. This should be very light, very easy to use, and targeted to casual users.

Of these, the proposed structure addresses the first point. The second point will be a useful side-effect of this. In addition, I propose that we begin dating release- or time-sensitive information to aid with this filtering process, both for site editors and for visitors.

I do not believe that we should address the goals of allowing annotations to all developer pages, addressing Scratchbox issues, and providing sample stylesheets for MicroB within the scope of revising the developer page structure. I propose that bugs be opened for specific issues and that these be addressed separately at some future date.

Related pages:

[edit] Proposed wireframe

Or: Why Dave is not a Designer

Core ideas: Simple block structure with developer-oriented RSS feeds in the sidebar.


[edit] Design proposal

Or: Why Andre and Glaubert do graphical design