Maemo Wiki Mirror - User contributions [en]

Task:Package categories

2008-11-11T20:06:03Z

81.25.53.121: /* Translations */

{{task|completed}}

This wiki page serves as a discussion page for improving the categorization system used for Maemo packages. Improvements here will be pushed to the [http://maemo.org/forrest-images/pdf/maemo-policy.pdf Maemo Packaging Policy] through [[Task:Packaging policy proposed changes]].

This proposal is coordinated by [[User:Xfade|Niels Breet]] and is part of the [[Extras_repository_process_definition|Extras repository process definition]].

== Problem ==

People feel the need to create new categories, because the current list is too limited.

Another problem is that some categories aren't very descriptive. What applications go in to tools, support or accessories?

== Maemo Packaging Policy ==

The current [http://maemo.org/forrest-images/pdf/maemo-policy.pdf Maemo Packaging Policy] lists the following sections:

* accessories
* communication
* games
* multimedia
* office
* other
* programming
* support
* themes
* tools

== New list for Diablo ==

This is the [http://lists.maemo.org/pipermail//maemo-developers/2008-October/035437.html final] list for Diablo:

{| class="wikitable"
! Key
! Example English i18n
! Example apps
|-
| user/desktop
| Desktop
| Home, statusbar and taskbar applets
|-
| user/development
| Programming
| py2deb
|-
| user/education
| Educational
| Flashcard apps
|-
| user/games
| Games
| Doom, Duke Nukem 3D
|-
| user/graphics
| Graphics
| Photo apps, GIMP, Inkscape, fonts
|-
| user/multimedia
| Multimedia ''or'' Sound & Video
| Canola, mplayer, Kagu, UKMP, MediaBox
|-
| user/navigation
| (Location &) Navigation
| maemo-mapper, Navit
|-
| user/network
| Internet & Networking
| Web browsers, Samba clients, OpenAFS, Transmission
|-
| user/office
| Office
| GPE, Claws, AbiWord
|-
| user/science
| Science
| gnuplot, Octave
|-
| user/system
| System
| rotation-support, enhanced kernels, themes
|-
| user/utilities
| Utilities ''or'' Accessories
| Calculators, terminals, text editors
|-
|}

If the package's section starts "user/", but is not any of the above, the ''Application Manager'' forces them into an "Other" section.

== Future additions ==

The current proposed list is only for Diablo, future additions and changes will be considered for Fremantle.

=== Debtags ===

Debian Package Tags: Faceted Classification

As stated on the [http://debtags.alioth.debian.org/faceted.html debtags website]:

{{quotation|Drawing a bit freely from the literature of Faceted Classification, a facet is a group of tags which describe the same quality of a package. Package Tags are organized in Facets, that represent different points of view from which to look at the package archive. For example, you could have a "Usage" facet with tags about what a program is intended to be used for, or you could have a "Media" facet with tags about what kind of information a program is able to process, a "Technology" facet about the technology a package uses, and so on. With this approach, every tag is situated in a specific context, and has a clear meaning. Also, tags from different facets shed light on packages from different points of view, giving "depth" to its categorization. Take something tagged with "Use::Chatting", "Technology::IRC", "Role::Server": it has a remarkable level of detail, and tells almost everything we need to know about what the package does.}}

=== Application-specific subcategories ===

Within each of the top-level categories, projects may want to group a number of packages together. For this, sub-sections can be used. For example, Canola may have:

{| class="wikitable"
! Package
! Section
|-
| canola2
| user/multimedia/Canola
|-
| canola2-theme-flatblack
| user/multimedia/Canola/themes
|-
| canola2-youtube-plugin
| user/multimedia/Canola/plugins
|-
| canola-tuning
| user/multimedia/Canola/settings
|}

The rule is simple:
# If the portion of the section path starts with a capital letter, it is shown as-is
# Otherwise the portion of the section path must be one of the above sections or, additionally:
#* themes
#* plugins
#* translations

== Translations ==

{| class="wikitable"
! Key
! en_GB
! en_US
! es_MX
! nl_NL
! pt_BR
! no_NO
! fi_FI
! it_IT
! fr_CA
! da_DK
! pt_PT
! sv_SE
! fr_FR
! es_ES
! ru_RU
! de_DE
|-
| user/desktop
| Desktop
| Desktop
|
|
|
|
|
|
|
| Skrivebord
|
|
| Bureau
| Escritorio
| Десктоп
| Desktop
|-
| user/development
| Programming
| Programming
|
|
|
|
|
|
|
| Programmering
|
|
| Programmation
| Programación
| Программирование
| Entwicklung
|-
| user/education
| Educational
| Educational
|
|
|
|
|
|
|
| Undervisning
|
|
| Education
| Educación
| Образование
| Bildung
|-
| user/games
| Games
| Games
|
|
|
|
|
|
|
| Spil
|
|
| Jeux
| Juegos
| Игры
| Spiele
|-
| user/graphics
| Graphics
| Graphics
|
|
|
|
|
|
|
| Grafik
|
|
| Graphiques
| Gráficos
| Графика
| Grafik
|-
| user/multimedia
| Multimedia
| Multimedia
|
|
|
|
|
|
|
| Multimedier
|
|
| Multimedia
| Multimedia
| Мультимедия
| Multimedia
|-
| user/navigation
| Location & Navigation
| Location & Navigation
|
|
|
|
|
|
|
| Position og Navigation
|
|
| Localisation et Navigation
| Localización y Navegación
| Позиционирование и Навигация
| Position & Navigation
|-
| user/network
| Internet & Networking
| Internet & Networking
|
|
|
|
|
|
|
| Internet og netværk
|
|
| Internet et Réseaux
| Internet y Redes
| Интернет и Сети
| Internet & Netzwerk
|-
| user/office
| Office
| Office
|
|
|
|
|
|
|
| Kontor
|
|
| Bureautique
| Oficina
| Оффис
| Büro
|-
| user/science
| Science
| Science
|
|
|
|
|
|
|
| Videnskab
|
|
| Science
| Ciencia
| Наука
| Wissenschaft
|-
| user/system
| System
| System
|
|
|
|
|
|
|
| System
|
|
| Système
| Sistema
| Система
| System
|-
| user/utilities
| Utilities
| Utilities
|
|
|
|
|
|
|
| Værktøjer
|
|
| Utilitaires
| Utilidades
| Утилиты
| Werkzeuge
|-
|}

== Reference ==

=== freedesktop.org ===

The basic, rationalised, set of high-level sections according to the [http://standards.freedesktop.org/menu-spec/latest/apa.html freedesktop.org menu specification] are: ''Accessories, Development, Education, Game, Graphics, Multimedia, Network, Office, Settings, System''.

=== Debian ===

The Debian archive maintainers [http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections provide] the authoritative list of sections. At present, they are: ''admin, comm, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11.''

=== Previous discussions ===

* [http://communitizer.blogspot.com/2008/04/rfc-maemo-package-guidelines-mandatory.html Communitizer blog]
* [http://lists.maemo.org/pipermail/maemo-developers/2008-April/033093.html Mandatory categories discussion]

=== Bugs ===

{{#bugzilla:id=1805
|columns=id, priority, severity, modified, product, status, summary, to
}}

[[Category:Community]]

Task:Package categories

2008-11-11T20:05:08Z

81.25.53.121: /* Translations */

{{task|completed}}

This wiki page serves as a discussion page for improving the categorization system used for Maemo packages. Improvements here will be pushed to the [http://maemo.org/forrest-images/pdf/maemo-policy.pdf Maemo Packaging Policy] through [[Task:Packaging policy proposed changes]].

This proposal is coordinated by [[User:Xfade|Niels Breet]] and is part of the [[Extras_repository_process_definition|Extras repository process definition]].

== Problem ==

People feel the need to create new categories, because the current list is too limited.

Another problem is that some categories aren't very descriptive. What applications go in to tools, support or accessories?

== Maemo Packaging Policy ==

The current [http://maemo.org/forrest-images/pdf/maemo-policy.pdf Maemo Packaging Policy] lists the following sections:

* accessories
* communication
* games
* multimedia
* office
* other
* programming
* support
* themes
* tools

== New list for Diablo ==

This is the [http://lists.maemo.org/pipermail//maemo-developers/2008-October/035437.html final] list for Diablo:

{| class="wikitable"
! Key
! Example English i18n
! Example apps
|-
| user/desktop
| Desktop
| Home, statusbar and taskbar applets
|-
| user/development
| Programming
| py2deb
|-
| user/education
| Educational
| Flashcard apps
|-
| user/games
| Games
| Doom, Duke Nukem 3D
|-
| user/graphics
| Graphics
| Photo apps, GIMP, Inkscape, fonts
|-
| user/multimedia
| Multimedia ''or'' Sound & Video
| Canola, mplayer, Kagu, UKMP, MediaBox
|-
| user/navigation
| (Location &) Navigation
| maemo-mapper, Navit
|-
| user/network
| Internet & Networking
| Web browsers, Samba clients, OpenAFS, Transmission
|-
| user/office
| Office
| GPE, Claws, AbiWord
|-
| user/science
| Science
| gnuplot, Octave
|-
| user/system
| System
| rotation-support, enhanced kernels, themes
|-
| user/utilities
| Utilities ''or'' Accessories
| Calculators, terminals, text editors
|-
|}

If the package's section starts "user/", but is not any of the above, the ''Application Manager'' forces them into an "Other" section.

== Future additions ==

The current proposed list is only for Diablo, future additions and changes will be considered for Fremantle.

=== Debtags ===

Debian Package Tags: Faceted Classification

As stated on the [http://debtags.alioth.debian.org/faceted.html debtags website]:

{{quotation|Drawing a bit freely from the literature of Faceted Classification, a facet is a group of tags which describe the same quality of a package. Package Tags are organized in Facets, that represent different points of view from which to look at the package archive. For example, you could have a "Usage" facet with tags about what a program is intended to be used for, or you could have a "Media" facet with tags about what kind of information a program is able to process, a "Technology" facet about the technology a package uses, and so on. With this approach, every tag is situated in a specific context, and has a clear meaning. Also, tags from different facets shed light on packages from different points of view, giving "depth" to its categorization. Take something tagged with "Use::Chatting", "Technology::IRC", "Role::Server": it has a remarkable level of detail, and tells almost everything we need to know about what the package does.}}

=== Application-specific subcategories ===

Within each of the top-level categories, projects may want to group a number of packages together. For this, sub-sections can be used. For example, Canola may have:

{| class="wikitable"
! Package
! Section
|-
| canola2
| user/multimedia/Canola
|-
| canola2-theme-flatblack
| user/multimedia/Canola/themes
|-
| canola2-youtube-plugin
| user/multimedia/Canola/plugins
|-
| canola-tuning
| user/multimedia/Canola/settings
|}

The rule is simple:
# If the portion of the section path starts with a capital letter, it is shown as-is
# Otherwise the portion of the section path must be one of the above sections or, additionally:
#* themes
#* plugins
#* translations

== Translations ==

{| class="wikitable"
! Key
! en_GB
! en_US
! es_MX
! nl_NL
! pt_BR
! no_NO
! fi_FI
! it_IT
! fr_CA
! da_DK
! pt_PT
! sv_SE
! fr_FR
! es_ES
! ru_RU
! de_DE
|-
| user/desktop
| Desktop
| Desktop
|
|
|
|
|
|
|
| Skrivebord
|
|
| Bureau
| Escritorio
|
| Desktop
|-
| user/development
| Programming
| Programming
|
|
|
|
|
|
|
| Programmering
|
|
| Programmation
| Programación
| Программирование
| Entwicklung
|-
| user/education
| Educational
| Educational
|
|
|
|
|
|
|
| Undervisning
|
|
| Education
| Educación
| Образование
| Bildung
|-
| user/games
| Games
| Games
|
|
|
|
|
|
|
| Spil
|
|
| Jeux
| Juegos
| Игры
| Spiele
|-
| user/graphics
| Graphics
| Graphics
|
|
|
|
|
|
|
| Grafik
|
|
| Graphiques
| Gráficos
| Графика
| Grafik
|-
| user/multimedia
| Multimedia
| Multimedia
|
|
|
|
|
|
|
| Multimedier
|
|
| Multimedia
| Multimedia
| Мультимедия
| Multimedia
|-
| user/navigation
| Location & Navigation
| Location & Navigation
|
|
|
|
|
|
|
| Position og Navigation
|
|
| Localisation et Navigation
| Localización y Navegación
| Позиционирование и Навигация
| Position & Navigation
|-
| user/network
| Internet & Networking
| Internet & Networking
|
|
|
|
|
|
|
| Internet og netværk
|
|
| Internet et Réseaux
| Internet y Redes
| Интернет и Сети
| Internet & Netzwerk
|-
| user/office
| Office
| Office
|
|
|
|
|
|
|
| Kontor
|
|
| Bureautique
| Oficina
| Оффис
| Büro
|-
| user/science
| Science
| Science
|
|
|
|
|
|
|
| Videnskab
|
|
| Science
| Ciencia
| Наука
| Wissenschaft
|-
| user/system
| System
| System
|
|
|
|
|
|
|
| System
|
|
| Système
| Sistema
| Система
| System
|-
| user/utilities
| Utilities
| Utilities
|
|
|
|
|
|
|
| Værktøjer
|
|
| Utilitaires
| Utilidades
| Утилиты
| Werkzeuge
|-
|}

== Reference ==

=== freedesktop.org ===

The basic, rationalised, set of high-level sections according to the [http://standards.freedesktop.org/menu-spec/latest/apa.html freedesktop.org menu specification] are: ''Accessories, Development, Education, Game, Graphics, Multimedia, Network, Office, Settings, System''.

=== Debian ===

The Debian archive maintainers [http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections provide] the authoritative list of sections. At present, they are: ''admin, comm, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11.''

=== Previous discussions ===

* [http://communitizer.blogspot.com/2008/04/rfc-maemo-package-guidelines-mandatory.html Communitizer blog]
* [http://lists.maemo.org/pipermail/maemo-developers/2008-April/033093.html Mandatory categories discussion]

=== Bugs ===

{{#bugzilla:id=1805
|columns=id, priority, severity, modified, product, status, summary, to
}}

[[Category:Community]]

Talk:Task:100Days

2008-06-03T05:07:32Z

81.25.53.121: /* A few suggestions for developers */

== Scope of the 100 Days ==

Hi, just a comment: anything inside maemo.org-the-webiste fits inside the range of things that the community, the maemo.org team and myself as Nokia contact can push forward without much discussion and interference if we all agree on the appropriatness and feasibility.

Anything related to software in the platform itself (as opposed to the server infrastructure), has many other stakeholders and dependencies and therefore fall out of the scope of the maemo.org planning exercise. If you want to compile these ideas and proposals fine, but it would be really useful to keep in this page the scope on purely maemo.org, its content, processes, servers, tools... and the people collaborating around it.

More or less the same principle applies to the [[2010 Agenda]] but in that case the discussion is more strategy and some software platform related topics might be more on topic.--[[User:qgil|qgil]] 13:29, 30 May 2008 (UTC)

== A few suggestions for developers ==
A few more suggestions for developers - the bottom rungs of the ladder.

1. Validate and verify the tools installation for the current shipping version, particularly the HOWTO. I follow the instructions but nothing builds. At least until I do an apt-get dist-upgrade, update, upgrade or something similar, then apt-get the -dev versions of a half dozen things, none of which is mentioned. Which brings me to:

2. Insure the hello-world will actually build on a system cleanly installed following the exact instructions from step 1. (I had to edit things in mine) and form a deb which will work on a tablet - both install and remove. Also split out stand-alone versions to use as templates (I can't get a statusbar only version to come up as everything seems to be interdependent). Maemopad is a great write template, but a paint template (slightly more than trivial graphic demo) would be nice.

Hildon is not something I've dealt with, and has its own quirks along with GTK. They aren't bad, but I could spend a week just learning the ins and outs. But there aren't very many examples I can just change the icons and add in a chunk of code to do a simple task as a starting point, at least not without doing a lot of searching (e.g. some statusbar clocks are stand-alone).

3. Simplify the autogen/automake/autoconf stuff. Most of this will only be run under fixed releases, so the checking for some specific version of 20 libraries is redundant, and makes the build horribly complicated. Either in scratchbox things are there or not (and see #1 above if they are not! I also have to keep doing apt-gets since I need -dev of everything and often don't have them). Do I really need libtool for a trivial statusbar app?

:Autoconf is actually quite important for code portability, not only across maemo releases (1.0, 1.1, mistral, scirocco, bora, chinook, diablo and so on) but also (and more importantly) across platforms. There is a lot of cross-pollination happening right now, and that's a very good thing IMHO. It will make your life much easier when you decide to port your application to (for example) Ubuntu Mobile, Openmoko or "desktop" GNOME, and it also makes porting stuff from other platforms to maemo simpler.
: Having said that, it is a bit of a learning curve, but perhaps what's needed is more entry-level documentation/tutorials (chapter 5 is a very good start at that) and tools to simplify bootstrapping (like the anjuta plugin).
:: Autoconf is not necessary to write portable software, while making your makefiles unreadable. Therefore, its use has to be made optional.

The goal is that anyone should be able to do a working deb for a trivial off-the-cuff application or status bar, home, or control panel applet in 5 minutes by doing a global substitute (or perhaps changing a few lines of the form: #define APPNAME HILDON_HELLO_WORLD, #define AppName HildonHelloWorld, #define appname hildon_hello_world, etc.) and adding a few lines of code and scaled icons.

And for "garage", there should be one centralized repository, so there would be a "garage" parallel to "extras" with all betas and releases not higher up in the chain. Right now I've got dozens of archives and sources, so when I do a restore it becomes a nightmare getting all the applications back and it makes application manager slower having to go through dozens of archives. It doesn't help having a "garage page" if it is not much better than hosting offsite. But then for all these add-ons I could just do apt-get source and/or apt-get install. Maybe this is what "extras" is for, but it seems to never work or have anything. —Preceding unsigned comment added by [[User:70.209.165.167|70.209.165.167]] 19:32, 29 May 2008 (UTC)

== Mostly Technical Suggestions ==

=== Development ===

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.

=== Discussion Forums ===

1. Fix iTT's style sheets so that they work well on MicroB! It is a joke that a site dedicated to internet tablets cannot be effectively viewed with an internet tablet.
: Just stylesheets may not be enough - the real problem lies elsewhere: run a Firebug Net test and look at the results - seems like right now the front page is 700k, delivered by 67 requests. Some things take seconds to load, some javascripts are with php extension, thus not using cache, taking precious bandwidth and seconds to load, I'm not sure I see the reason for that. Things that can be done to get it faster - javascript libraries can be compressed with YUI compressor for instance and not served with php so they can cache properly, replace youtube videos with handy links for mytube just for ITs, combine stylesheets and javascripts together, reducing requests, use fewer PNGs with alpha, if any - Cairo probably will have a good deal of trouble displaying them on an IT. [[User:bundyo|bundyo]] 20:44, 30 May 2008 (UTC)
:: Umgh... I did notice the stylesheet but did not know it was that bad. My suggestion would be to simplify the page rather than use compressor, etc. There is absolutely no reason for this page to be this complicated and take 700kB. It is not doing anything special, just presenting a few views to the reader. Really hope Reggie sees the light at some point and changes his setup. —Preceding unsigned comment added by [[User:fms|fms]] 17:19, 30 May 2008 (UTC)
:Though definitely something that needs doing, it's a bit out of scope for maemo.org. ;) Somebody want to run through the areas where Reggie could optimized and open a thread in the [http://www.internettablettalk.com/forums/forumdisplay.php?f=16 Comment/Suggest] forum over there? —[[User:generalantilles|generalantilles]] 21:22, 30 May 2008 (UTC)
::another itT redesign (tablet-friendly) is planned. --[[User:rsuplido|Reggie]] 20:54, 2 June 2008 (UTC)
2. Integrate iTT with Maemo.org karma system.
:See [https://bugs.maemo.org/show_bug.cgi?id=2303 bug #2303] and [https://bugs.maemo.org/show_bug.cgi?id=2304 bug #2304] —[[User:generalantilles|generalantilles]] 00:25, 1 June 2008 (UTC)

=== Software Distribution ===

1. Actively hunt on the Net for maemo apps not yet added to Maemo Extras, talk to developers, ask and help them to commit applications to Maemo Extras. This especially applies to app porters currently active at iTT.

2. Use gronmayer's scripts to create a web site that merges applications from all known repositories into a single list and lets you browse them with MicroB using HTML UI similar to N-Gage, Apple Store, etc. While it sounds ambitious, it is not difficult to do, as we always have app descriptions and icons (form .deb files) and we also have screenshots for apps hosted at Garage. Reformatting this data in a format that can be nicely presented in tablet browser is not difficult.

3. Effectively replace "iTT Software Section" with #2 from this list.

:: About 2 and 3 - I thought we all agreed on that here: http://www.internettablettalk.com/forums/showthread.php?t=20261, just compiling a single list won't solve the dependency hell. [[User:bundyo|bundyo]] 19:04, 30 May 2008 (UTC)

:: It will not but then it is not the goal of 2. The goal is to supplement the current half-baked Application Installer app with a quickly modifiable online interface for searching and selecting applications. This will help users to find more applications and in the same time it will help developers to figure out just how exactly application installer should work. Instead of waiting for the next OS release, it is really easy to modify the web interface and see which modification is better. Later, the real App Installer can be designed to have the same or similar interface.
::: I can see what your idea is, but i don't think the user will be happy when his/her NIT falls into a reboot loop due to some library replacement. Not good for official, but maybe will be good for the developers to see what is already ported and not doing it again. [[User:bundyo|bundyo]] 20:49, 30 May 2008 (UTC)
:::: Situation where a library used by some other application is being upgraded can be checked and reported to the user, as a warning. And no, of course I do not suggest that this system is associated with Nokia in any way: Nokia can't be held responsible for all the repositories out there.
::::: Well, then it should be discussed as kind of an upgrade to Gronmayer's site, maybe with him? [[User:bundyo|bundyo]] 21:35, 30 May 2008 (UTC)
:::::: Definitely: after all, he has all the code already. Replicating it is extra work. As to the UI, I have got a mock up already, if anybody is interested (http://fms.komkon.org/Maemo/). [[User:fms|fms]]

== Growing the community through better information for newcomers ==

* Currently, maemo.org structure is less than favourable for newcomers to get familiar on what maemo software and maemo.org is. If we want to grow the community we need to provide better introduction to the community and the software assets. Hence, the content of the Intro section should be refreshed and restructured.
* To create more clarity, I would suggest to remove the "Tips for tablet users" because the link to OS2008 web page is already on the home page. I would furthermore move the "Roadmap" page to the "development" section. The gallery page should be moved to "downloads" and someone should clean up the gallery to contain only relevant content. The presentation section is to some degree outdated and should also be cleaned up. The "White Paper" page should be really give a quick overview of what maemo software is. The "trademark" and "licenses" pages should be moved to "Terms of Use". And the "Links" should be moved to "Development".
* After all these changes, our intro section should include "Who is the maemo community?, What is the maemo platform? The maemo software architecture, How does maemo.org work? Quick start guide to develop on maemo software, and presentations" --[[User:peterschneider|peterschneider]] 10:02, 30 May 2008 (UTC)

== Smoothing the introduction of new users to maemo.org ==

* The development section should be organized in a simple, clear and centralized way to beginners. The following information is important and should be presented to the newcomers immediately they enter the development section.
# Simple steps of getting started should be presented in a clear and definite way ,on a conspicuous area with color. for example:
## Sign up a maemo account (link to register page)
## Download and set up development environment.(link to detailed method page)
## Create hello world application, Package and Test(link to several typical and simple examples,and useful links to advanced docs should be included)
## Collaboration on maemo.org and Launch app on the download section (link to pages including usage of project homepage)
# Key features of maemo platform should be presented on the section page explicitly.
## Free to develop and launch applications.
## Powerful enough to create advanced applications.
## Flexibility in programming (Gtk+/C,Python,Qt and etc)
## Easy to port existing application.
# Wiki on frequent technical problems in programming(the how-tos part),and entry to developer's disscusion board(link to ITT's or a new one) to help newcomers to find solutions to difficulty and ask for help.
# All docs in a catalog with good classification for look up.
# Maemo's roadmap and history, technical news and announcement about maemo.
# Maemo app gallery and entry to experienced and recently active developers' tech blogs.

== Style and accessibility of maemo.org ==

There are some consistency problems with the clarity of the maemo.org web sites. Although some are simply visual clutter, and not critical, some definitely obscure important links; a notable example is the complete list of applications. It appears to be simply a heading, as it matches the color and font of all the other headings.

garage.maemo.org does not seem to have this problem, all links are underlined, and the traditionally expected color for links.

References regarding link accessibility are easily found (a google search for "underlined link usability" brings back a great deal of useful links). Here are a handful.

* Excellent [http://www.useit.com/alertbox/20040510.html accessible link overview] by Jakob Nielsen
* Nice writeup regarding [http://www.uie.com/brainsparks/2006/07/05/do-links-need-underlines/ user expectations] when reading links
* A [http://www.usability.gov/pubs/052007news.html US Government site on accessibility]. Note that they suggest avoiding "non traditional colors for links" although this is never really strictly held to in most web sites. Colors should always mean the same things, however.
* Another [http://www.webcredible.co.uk/user-friendly-resources/web-usability/effective-link-text.shtml nice article] summarizing the best use of links. The article also references many other similar articles.

Hover effects can be useful and attractive, but with a stylus-oriented browser, you cannot practically hover the cursor at all.

We all want a pleasant, modern and attractive web site on both tablet and desktop. A nice solution is to make a light-colored underline that darkens as you hover. This is easily done, and supported across all modern browsers:

<code>
a,a:link,a:visited { text-decoration:none; border-bottom: 1px solid grey; color: red;}
a:hover,a:active { border-bottom: 1px solid red;}
</code>

Here visited links are not differentiated from unvisited links. It is recommended to do so, but uncommon; I suspect users wouldn't notice.
--[[User:boxofsnoo|boxofsnoo]] 02:42, 1 June 2008 (UTC)

== How can I help? ==

How can I help in this process, as one of the people responsible of the maemo.org planning at Nokia? I could help organizing the content, identifying what is out of scope or what more realistically falls in the Agenda 2010. Or I could just shut up and let you work. :) fyi, in the meantime I'm already working on the maemo.org short and mid term plans internally at Nokia. --[[User:qgil|qgil]] 19:05, 1 June 2008 (UTC)
:I don't think a little direction will repress things too much at this point, and I definitely thing it will help stimulate and focus the brainstorm. Not only because of the clearer definition of purpose, scope and direction, but also from the interest a more visible Nokia involvement would make. The end result, of course, being a much more productive session. --[[User:generalantilles|generalantilles]] 20:15, 1 June 2008 (UTC)
::I will start leaving signed comments, not to touch the original text. Then you decide what to do with it.--[[User:qgil|qgil]] 06:20, 2 June 2008 (UTC)

== Clear and useful planning pages ==

The 100 days page is getting longer. I think at the end what we all want to have is a list of clear actions, being most/all of them links to pages where each action is discussed and planned in detail. Proposal to get there:
* Create pages for those topics that already got interest and meat enough. Move there all their related ideas and comments. This includes the content in this discussion lisrt, since having it hidden here or even duplicated is not going to help.
* Put at the top the items that are pre-agreed: no-brainer stuff, items with lots of community support, items already acceopted by Nokia and/or the maemo.org guys.
* New good ideas are added in the bottom and end up either in the top after being pre-agreed, or moved to other existing pages.
--[[User:qgil|qgil]] 08:09, 2 June 2008 (UTC)

Task:100Days

2008-06-02T07:23:53Z

81.25.53.121: /* maemo "Application Store" */

The '''maemo.org 100 Days Action Plan'''

{| style="background-color:#f4f09c; border: 1px silver solid; padding: 10px;"
| [[Image:50px-Nuvola apps important yellow.svg.png|50px|left]]
|
* '''Please login''' before making any changes. '''Thank you'''.
* Please keep things '''on-topic'''.
* '''Hardware requests''' are entirely ''out-of-scope'' and will be removed by community members trying to keep this page focused and on-topic.
* '''Software requests''' which would be trivial for a third party to provide — or are already on the roadmap — are ''out-of-scope'' and will be removed by community members trying to keep this page focused and on-topic.
* Don't put things which aren't feasible in '''3 months'''. For long term suggestions, consider adding them at [[2010_Agenda|maemo.org 2010]].
* Discussion of the 100 Days agenda should be held in the [[Talk:100Days|discussion page]].
|}

==Get the server and bandwidth infrastructure up to speed==
Although things have improved some (particularly after the OS2008 release), they don't seem to be keeping up well with the ever increasing numbers of tablet users, and downtime or slowness from the critical services offered by maemo.org is unacceptable.
* Mirror repository.maemo.org to ensure good uptime and fast response.
* Mirror tablets-dev.nokia.com to ensure good uptime and fast response.
* Improve the hardware and bandwidth availability behind *.maemo.org to ensure good uptime and fast response—maemo.org is too slow!
:This work is ongoing and the results should be noticed way before the end of the 100 Days.--[[User:qgil|qgil]] 06:24, 2 June 2008 (UTC)

== Increase openness ==
Openness is a significant part of what makes maemo so strong, putting together a plan for addressing closed-source components (particularly those directly controlled by Nokia (e.g. low-level stuff like mce and dsme, and user-space stuff like tablet-browser and the task/statusbar applets).
:Perhaps ''Map openness'' would be a more accurate description, specially for the 100 Days. Nokia has not the goal of shipping a 100% open source platform. Open source is the recommended approach, but closed source is used when it offers a differentiator, an advantage over competitors. But it is good to get a common understanding on why Nokia is shipping component X as closed source, and answer when possible to requests about opensourcing something.--[[User:qgil|qgil]] 06:46, 2 June 2008 (UTC)

=== The plan ===
* Identify all components (a module name isn't enough). Be like GNOME's release set list.
* Identify all closed components in the OS at each layer:
** Initfs/direct hardware access
** Firmware used by kernel modules (Wifi, Bluetooth)
** Low-level system daemons (mce, dsme)
** User-space applications (tablet-browser, applets)
* For each package:
** Outline purpose in a dedicated wiki page.
** Describe the closed-source rationale.
*** ''Will need some form of mediawiki template for such pages --[[User:jaffa|jaffa]] 22:26, 29 May 2008 (UTC)''
* Document the process for working towards opening the component, or its specification.
* Ensuring any new closed packages get a wiki page containing their rationale.
:Yes, we can do or at least start something along these lines in the 100 Days. What about getting into details about this plan in a page apart, to keeop the main page clean? (same would apply to the rest of actions taken) Let's also see to the potential starting points i.e. [http://maemo.org/development/documentation/how-tos/4-x/maemo_architecture.html the maemo architecture] and the [http://tablets-dev.nokia.com/4.0.1/4.0_vs_4.0.1_content_comparison.html list of packages].--[[User:qgil|qgil]] 06:46, 2 June 2008 (UTC)

== Software distribution ==
=== The website ===
* Implement some sort of automated single-click push-to-Downloads for Garage projects.
:Interesting idea. What about the feasibility? Niels? Ferenc? In any case integrating Garage with Downloads make a lot of sense, and the question is whether this would fit in the 100 Days or later.--[[User:qgil|qgil]] 06:59, 2 June 2008 (UTC)

==== [http://www.internettablettalk.com Internet Tablet Talk] Syndication ====
* Provide an automatic way to syndicate applications to the Internet Tablet Talk Software Section (itTSS).
* Each application (version) that is syndicated on Internet Tablet Talk, starts a new thread in the forums so end-users get notified of new apps as well as provide a way to give feedback to the developers. Developers themselves can also join in the discussion. This, hopefully, will help to better the quality of applications.
** ''What would be the point of most the garage facilities then? I am not convinced that developers will all go looking at ITT for feedback (some projects work like that, but most rely on mailing lists and irc for example). If there was to a ITT thread for user feedback then maybe add to it a big fat 'report a bug on package x' or 'contact developers of package x'. '' --[[User:trickie|trickie]] 12:17, 1 June 2008 (UTC)
* Provide a way for developers to easily add a bug at the application's Garage page for confirmed bugs reported in the discussion thread.
:We have agreed with ITt on the general idea. It's something urgent and it would be definitely good to see it in the 100 Days. The specific plan to be discussed in an open page, either here or in ITt or both. In any case, it's clear that the feature is "syndication". Then ITt or whoever can benefit from that, and are the developers of each piece of software that decide if they want to direct the user feedback to ITt, their garage project, the project website, etc.--[[User:qgil|qgil]] 06:59, 2 June 2008 (UTC)

==== maemo "Application Store" ====
* Actively hunt on the Net for maemo apps not yet added to Maemo Extras, talk to developers, ask and help them to commit applications to Maemo Extras. This especially applies to app porters currently active at iTT.
* Use gronmayer's scripts to create a web site that merges applications from all known repositories into a single list and lets you browse them with MicroB using HTML UI similar to N-Gage, Apple Store, etc. While it sounds ambitious, it is not difficult to do, as we always have app descriptions and icons (form .deb files) and we also have screenshots for apps hosted at Garage. Reformatting this data in a format that can be nicely presented in tablet browser is not difficult.
* Effectively replace "itTSS" with this website.
* Actively convince maintainers of other repositories to join the maemo extras repository. This would save some headache from offline and broken repositories.
* Make sure that all applications which are actually available in the repositories can be found in the Maemo.org downloads section.
:From a Nokia point of view the interest is to have a single repository for distributing third party applications. External repositories should be an exception targeting very specific needs and users. Nokia is not interested in blurring the boundaries between a community supported extras repository and the repo someone has setup somewhere.--[[User:qgil|qgil]] 06:59, 2 June 2008 (UTC)
::While it is obviously better to have a single repository, both for users and for Nokia, realistically it is not going to happen soon. So, there is still a place for a repo aggregator like Gronmayer to exist. Additionally, creating an AppInstaller-like AJAX web site for Gronmayer specifically targeted for displaying in MicroB will let you test different AppInstaller designs before implementing them in a real application and pushing them to the users. It is really easy to change a piece of PHP code but changing a native app and updating everybody's tablets with it is more dofficult. [[User:fms|fms]]

=== The repositories ===
* Again, because this can't be stressed enough, get the infrastructure behind the repositories up to speed—we need servers, we need bandwidth and we need mirrors.
* Streamline the acceptance system for Extras(-devel), (not necessarily easier or less stringent, but more straightforward and clear).
* Lay out the groundwork for a peer-review system for Extras acceptance (or devel to Extras promotion) to help ensure good quality assurance on its packages.

== Developer documentation ==
=== Clean out the cobwebs, remove the cruft ===
* Get what's still useful and mostly relevant completely up to speed for maemo 4.x.
* Archive the outdated information away from the maemo 4.x stuff.
* Mark the outdated stuff clearly.

=== Get organized ===
* Put together an easy-to-navigate, sensible index for the documentation content.
** Place references/howtos/tutorials onto one page so that developer does not need to click through several menus.
* Improve the search (google?).

=== Get focused ===
* Add porting FAQ wiki page detailing common problems developers will run into (i.e. application is killed 3 seconds after launch) and how to deal with them. Provide examples of typical GTK/Motif/etc. application changes needed to properly Hildonize the application. List ways to deal with porting of toolkit-specific functionality whether it be internationalization or mouse/keyboard input.
* Make it possible for logged-in developers to annotate any place in the documentation. Link to annotations from documentation.
* 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.
* Clearly define what changes is made by default on gtk : like GtkTreeView with hidden header columns by default, or image-button off ...

=== Look towards the future ===
* Define types of applications that will be useful on the Internet Tablet
* Stress the fact that the Internet Tablet is not a PC and apps should be created/ported with the tablet form in mind. Don't just do a direct port of an existing app. Aim for quality and Internet Tablet usability.
* Focused discussion/guide on User Interface so apps will have a consistent look as well as provide a similar way to interface with the user
* 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.

== maemo.org ==
* Re-write and expand Introduction to better serve as a useful introduction for newcomers to the platform.
** Intro section should include "Who is the maemo community?, What is the maemo platform? The maemo software architecture, How does maemo.org work? Quick start guide to develop on maemo software, and presentations".
* Single sign on for maemo.org/garage.maemo.org/wiki/bugzilla -> would make community participation easier and the 'karma' calculation (if needed) too.
* Website information does not suit the needs of newcomers: How to install or do xy on the IT? Where is recent information about OS2008? Is this page, which I am looking at, an outdated or a recent page on maemo.org? What resources are available for me (alias I am confused by unconnected information sources: gronmayer, internettablettalk, planet.maemo, official Nokia site, internettabletschool, maemo ...) Where is a detailed roadmap for Maemo? Is there an application wishlist for OS2008? Where can I give input/ideas as end-user?

=== Style and format ===
* Maemo.org can benefit from some face lifting - right now on 1280x1024 (this resolution seems to be very common to developers) only half of the real screen estate is used. With some loose block positioning both 800x480 and bigger resolutions can be supported. Maybe even specialized tablet finger-friendly look for those preferring it.
** ''Resolution seems fine to me at the moment, and it works fine on the tablet without requiring the extra effort of maintaining a separate tablet style. Perhaps reducing the min-width to not require horizontal scrolling with the tablet browser windowed would be useful, though. [[User:generalantilles|generalantilles]] 21:02, 29 May 2008 (UTC)''
*** ''There won't be any extra effort on the resolution maintainment - this can be done with minor CSS modifications. As for the separate tablet style - this really requires extra effort and if done should be entirely optional. [[User:bundyo|bundyo]] 21:26, 29 May 2008 (UTC)''
* More relevant information displayed on front page, preferably customizable blocks like Netvibes and iGoogle. Since the content is gzipped, that won't be too harming to the traffic. Blocks can be optionally auto updated for those that like to keep their browser pages open (and if Prizm is ported - even in the tray). For instance, a "new bugs" section with voting on the fly will boost bugzilla usage.
* Make links more standardized. New users often expect links would be underlined, even subtly, or appear to be a button of some kind. Don't rely on hover effects because the tablet can't practically use them. See [http://en.wikipedia.org/wiki/Mystery_Meat_Navigation Wikipedia on 'Mystery Meat Navigation']
** ''This is much less of an issue for a lot of people —[[User:generalantilles|generalantilles]] 19:49, 31 May 2008 (UTC)''
** ''Please stop expecting your advanced experience of new users. Read up on web accessibility, be inviting to the new users.''--[[User:boxofsnoo|boxofsnoo]] 23:08, 31 May 2008 (UTC)
*** ''I really don't see the issue (and never particularly have with this much-abused "Mystery Meat" nonsense), and I don't think it has anything to do with my experience, wikipedia (your source) uses the exact same system for link identification. . . . Some specific examples would probably help your case. Anyway, this should probably be taken to the talk page. —[[User:generalantilles|generalantilles]] 23:20, 31 May 2008 (UTC)''
* Format and style need to be unified across as much of the site as possible (excluding things like Garage and Bugzilla). Take, for instance [http://maemo.org/news/planet-maemo/ Planet] and [http://maemo.org/news/ News], two pages that should be very similar, if not the same. Perhaps take News' style and format and apply it to Planet (add the contributor's avatar to the upper right of each article? Much like [http://slashdot.org slashdot] does with their article category images.), as the News style seems to offer a cleaner look that better utilizes the available space.
* For the outliers like Garage and Bugzilla, at least the style should largely be unified with the main site—using the same fonts, same colors, etc.

== Communication ==
* Today we have too many channels (ITT, maemo.org...). Maybe have some more focus like: maemo.org for developers and ITT for end users and something that links them so software releases can be announced automatically on ITT and users from ITT can easily post bugs on garage bugzilla for example.
** ''Perhaps develop a plan, but this isn't specific enough to achieve in 3 months, IMHO --[[User:jaffa|jaffa]] 22:10, 29 May 2008 (UTC)''
*** ''I'm not convinced that two channels is too many, either. —[[User:generalantilles|generalantilles]] 20:04, 31 May 2008 (UTC)
* Develop a recommended usage policy for garage.maemo projects, taking into account turning off GForge modules not needed (perhaps defaulting in a subset rather than all, for new projects). Further discussions on whether non-core bugs should be in central Bugzilla and garage trackers merged/closed.
* Close misnamed (and now misused) maemo2midgard-discuss mailing list and create maemo-web alongside existing mailing lists for overall discussions about maemo.org sites.
* It's unclear where to report problems about packages found in the application catalog. A single bug tracker is needed, or at least a catalog that would redirect the user to the appropriate tracker from a common start page. Or we could set up a "maemo" distribution on launchpad.net, which would let us integrate with the bug trackers of individual packages.

== What the community needs to do ==
* Put together an plan of action for moving forward with a community-maintained Hacker Edition (based on what Quim said [http://www.archive.org/details/QuimGil-MaemoLinuxtag2008Update here])
* Put the pressure on developers:
** Encourage developers not using a repository to package their applications and push them to Extras(-devel), and get developers with 3rd-party repositories to close them down and push their stuff into Extras(-devel).
** Encourage developers to follow proper packaging guidelines (based on the draft [https://maemo.org/forrest-images/pdf/maemo-policy.pdf here]).
** Encourage developers launching applications on Downloads to include as much information about the application as possible (screenshots, good descriptions, good changelogs).

== Update developer libraries ==
* gcc-4.x, glib, powervr, it's important to give developers much more time to play with newer tools than short before a major upgrade takes place (of course with disclaimer that nothing is guaranteed to be shipped in a certain way)
* Update the vmware appliance with sb2 and python2.5 setted. And more publicity on the vmware appliance, as there is already one on garage, but many don't know it.