Application developer site

Revision as of 04:32, 15 March 2011

Overview

From the experiences of Apple and Android, we can assume that, if we are successful, there will be many more application developers than platform developers. Their needs will be different, as they are more interested in using APIs than designing them. The audience will consist of both beginners who need simple, clear, tutorials/walkthroughs, and experienced developers more interested in code samples and reference documentations.

Objectives

The goal of the developer.meego.com site is to present and market the Meego Application Developer offering. This needs to be of high quality on par with other application developer sites (Android, Palm, Drupal, KDE, Apple).

Status

The current status can be found here.

A bugzilla version is available here.

Tasks

All bugzilla tasks/bugs for developer.meego.com.

Critical tasks

See bugzilla list above.

Operating model

The operating model for DMC is proposed as follows:

DMC coordinator

Responsibilities include:

• Act as the primary advocate for the visitor
• Define tools and platforms
  • Wiki
  • Bugzilla
  • Performance and security (backups, etc)
• Develop guidelines for community
• Set targets and action plans
• Build alliances across the ecosystem
• Communicate with the community
• Arrange funding
• Arbitrate requirements handling
• Steer MeeGo brand deployment
• KPI definitions and monitoring
• Create incentives for contributions:
  • karma incentives
  • financial incentives
  • promotional materials
  • dev device distribution
  • event participation
• Manage the personas and user journeys across the ecosystem surrounding the site (w/content editors)
• Identify main content and capability gaps and needs for these journeys (w/content editors)

DMC Production Manager

Responsibilities include:

• Oversee minor and major platform releases
• Design aspects including:
  • usability
  • site IA (with content editors and coordinator)
  • design assets
  • CMS features
  • ensure MeeGo brand deployment
• Steer site improvement requests
  • Improvement requests process:
    • 1. need requested
    • 2. need validated
    • 3. development prioritised
    • 4. source found (production manager finds concept developers)
    • 5. developed
    • 6. tested
    • 7. release planned
    • 8. release
• Agree on production workload. Flexible, can be delegated/divided based on:
  • core skill
  • application module
  • and could also involve finding potential Linux foundation resources (which would influence role definitions etc.)

Drupal developers

Responsibilities include:

• Required participation in these steps of the improvement process:
  • 1. need requested
  • 4. source found
  • 5. developed

Content editors

Responsibilities include:

• Oversee content process:
  • 1. need requested (generally through Bugzilla)
  • 2. need validated: content editor validates against content plan
  • 3. source found: content editor finds contributors
  • 4. content created as draft (usually in wiki, but may be links in Bugzilla)
  • 5. Content reviewed (by community/other contributors/content editor)
  • 6. content released as approved (migrated to site by content editor or linked to wiki from DMC by content editor)
• Managing content plan:
  • managing personas/scenarios
    • developers
    • designers
    • technology thought leaders
    • lead users
  • prioritizing content requests
  • managing home and hub page editorially
  • managing content ecosystem
    • reach activities
    • social media monitoring
    • seo
• Manage content on site and across the ecosystem (for example Wikipedia and Youtube) resulting from the actions identified above
• Ensure quality of content (grammar, style, tone of voice, etc.) and relevance
• Agree on editorial workload
  • assume minimum 2 or 3 editors needed
  • workload by content type
  • workload by core skill
  • workload by language and localisation
  • workload by persona
  • workload by geography/timezone

Content contributors Responsibilities include:

• Participation needed in these parts of the content process:
  • 1. need requested (respond if skills suit request)
  • 3. source found (content bug assigned to contributor)
  • 4. content created as draft (usually in wiki, but may be links provided through Bugzilla)
  • 5. Content reviewed (by other contributors/community members/content editor)

About the tools used in the content/improvements management processes

• Bugzilla is used to manage both content and capability needs, for example wishlists, enhancements [FEA], future releases, current release maintenance fixes, incomplete areas, etc.
• Wiki is used for content drafting and staging for community content. Content in the wiki could be drafted and reviewed in iterations between the content creators and editor and placed on site when the creators and editors feel it is in a complete, quality assured format. For content that is under continual development, Wiki entries may also be divided into constant and variable sections, and linked accordingly in the site (with source marked whenever possible)
• Google Analytics may be used to track site use and conversion goals
• Roadmap, actions, issues are used to track development plans
• MeeGo mailing lists, forum, personal email (last resort), and Bugzilla used as communication

Content Description

The content description can be found from here.

The site should link to the related content listed here.

Content processes

As defined above in the operating model:

• 1. need requested (generally through Bugzilla)
• 2. need validated: content editor validates against content plan
• 3. source found: content editor finds contributors
• 4. content created as draft (usually in wiki, but may be links in Bugzilla)
• 5. Content reviewed (by community/other contributors/content editor)
• 6. content released as approved (migrated to site by content editor or linked to wiki from DMC by content editor)

Content Draft

A wiki version of the information architecture with draft content is available here.

Future Content

The current site could be enhanced with the following content.

1. Active meego architecture diagram

Development Process

Improvements/requirements development process as defined in the operating model above:

• 1. need requested (Bugzilla)
• 2. need validated (Production manager/coordinator)
• 3. development prioritized (Production manager/coordinator/community input)
• 4. source found (production manager finds concept developers) (drupal developer, designer, etc)
• 5. developed
• 6. tested
• 7. release planned
• 8. release

More about site development can be found here

Schedule

The original schedule was to have an initial site ready for Nokia Developer Summit, and Intel Developer Forum in mid-September. This has been change to match the schedule of the underlying project, With the site planned to be available in October aligned with the MeeGo 1.1 release.

Critical bugs fixed as of MArch 15. Awaiting approval from community for passwords to be lifted.

Site design

The draft information architecture can be found here here. It is open for comments and suggestions.

Some sample wireframe designs will be found here. These are open for comments/suggestions.

The full information architecture and complete wireframe set is available in .pdf here: File:DMC Design.pdf.

Here is the proposed layout and content overview for the homepage, plus footer redesign:

MOCKUP ONLY

After discussion with the maintainers of www.meego.com and the TSG it was felt that developer.meego.com diverged too much from the www.meego.com look&feel. The designers of developer.meego.com have generated an example of this:

MOCKUP ONLY

Project Team

MeeGo Project Manager

• Ronan Mac Laverty/macron,maclaver(IRC) - Nokia's Maemo (Application) Developer Advocate

Project Members

... People working on the project part-time funded by Nokia ...

• Teemu Lukkari/ttlukkar / Activeark / Project management, Design manager
• Graham Honeywill/harmaakinkku / Activeark / Project Communications, Analytics manager, Concept owner
• Tiffiny Rossi/verbosemode / Activeark / Content editor
• Mikael Kundert/mikaelkundert / Activeark / Drupal developer

Community Members

... People from the community involved in this project .....

• Dave Neary/dneary - maemo.org docmaster
• Dawn Foster/dawnfoster - Community Manager
• Michael Shaver/mshaver - Moblin.org webmaster & meego.com website developer
• Elliot Smith/townxelliot - MeeGo wiki maintainer & MeeGo SDK content editor
• bspencer - Bob Spencer

Contact People

Associated activities

The Developer Engagement Framework.