• Intro
• Downloads
• Community
• Development
• News
• TALK

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:
   • Instructions on downloading the SDK
   • A guide to getting a Scratchbox environment up & running
   • Links to the various useful tools (and more useful tools) & Eclipse integration
2. "Documentation" or "Knowledge base" or whatever we want to call it will include:
   • Quick Start Guide
   • The platform guide, including "Getting started", "Porting an application", and a guide to the components of the platform
   • Code samples
   • Training material - technology overview, getting started, application development and platform development
   • Link to (and a description of) the garage
   • Links to relevant material in the wiki
   • Links to useful external resources & articles, and kudos for upstream projects
   • A link to the relevant pages explaining how to promote an app in extras & maemo.org/downloads.
   • A link to the Maemo pages at Forum Nokia.
   • Note also the Maemo for Symbian & .Net developers documentation.
   • See Talk page Quality considerations

1. "Reference" will include:
   • Man pages - indexed and searchable
   • API docs for the platform - searchable!
2. "Get help" will include:
   • Reference to the developers mailing list (with an RSS feed of latest threads)
   • Pointer to IRC (no need to link to the page - simply refer to the channel)
   • Relevant material from the wiki (with an RSS feed of latest changes)
   • A link to Bugzilla, with reporting guidelines (and an RSS feed of recently (created/fixed/modified?) bugs)

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:

• Objective:Co-production_of_official_&_community_documentation + Use the wiki for developer documentation

[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