Task:Improving maemo.org/Development
(Copy page over from Content Cleanup) |
(→Proposed structure for development portal =) |
||
| Line 1: | Line 1: | ||
| - | == Proposed structure for development portal | + | == Proposed structure for development portal == |
This is a proposal for an improved structure for http://maemo.org/development | This is a proposal for an improved structure for http://maemo.org/development | ||
| Line 16: | Line 16: | ||
#* The platform guide, including "Getting started", "Porting an app", and a guide to the components of the platform | #* The platform guide, including "Getting started", "Porting an app", and a guide to the components of the platform | ||
#* Tutorials | #* Tutorials | ||
| + | #* HOWTOs | ||
#* Code samples | #* Code samples | ||
#* Training material - the technology overview, getting started, application development and platform development | #* Training material - the technology overview, getting started, application development and platform development | ||
Revision as of 19:59, 22 October 2008
Proposed structure for development portal
This is a proposal for an improved structure for http://maemo.org/development
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:
- "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 & Eclipse integration
- "Documentation" or "Knowledge base" or whatever we want to call it will include:
- The platform guide, including "Getting started", "Porting an app", and a guide to the components of the platform
- Tutorials
- HOWTOs
- Code samples
- Training material - the technology overview, getting started, application development and platform development
- Links to relevant material in the wiki
- Links to useful external resources & articles, and kudos for upstream projects
- "Reference" will include:
- Man pages - indexed and searchable
- API docs for the platform - searchable!
- "Get help" will include:
- Reference to the developers mailing list (with an RSS feed of latest threads)
- Reference to IRC
- Relevant material from the wiki (with an RSS feed of latest new pages)
- A link to Bugzilla, with posting guidelines (and an RSS feed of 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.
Other ideas from brainstorm
During the brainstorm, the following points were proposed as priorities:
- Place references / howtos / tutorials onto one page so that developer does not need to click through several menus.
- 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".
- Make it possible for logged-in developers to annotate any place in the documentation. Link to annotations from documentation.
- Switch to SB2. SB1 is difficult to install and stays insulated from the rest of developer's system, making development complicated.
- Provide an example of simple build environment *not* relying on AutoConf and its friends. A single includable makefile should suffice, when used with SB2.
- 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.
- 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: