Task:Content Cleanup - Revision history

imported_>dneary: Clean up page, reorganise sections, remove completed tasks

2008-10-01T15:36:41Z

Clean up page, reorganise sections, remove completed tasks

← Older revision		Revision as of 15:36, 1 October 2008
Line 4:		Line 4:
	Connected to [[Task:Improving maemo.org]]		Connected to [[Task:Improving maemo.org]]

	~~Dress~~ up the most important content~~, dump what is not relevant, handle via wiki the rest~~.		Break the site up according to various use-cases. For each part of the site, identify the most important content and put it up front.

	* ~~Get~~ what's still useful and mostly relevant ~~completely up~~ to ~~speed for maemo 4.x~~.		Outdated official content should not appear in the primary navigation of the site, but should be accessible in an archive - esp. 3.x downloads, API documentation, guides.

			The wiki can be one of two things - a sandbox for brainstorming or a repository for documentation. It's hard for it to be both.

			=== Site organisation ===

			* Use-case by use-case, figure out what the most important information on the site is, and make it easy to find.
			** Concentrate on the site structure more than the content.
			* If there is still useful and mostly relevant information which needs updating to the latest release, update.
	* Archive the outdated information away from the maemo 4.x stuff.		* Archive the outdated information away from the maemo 4.x stuff.
	* Mark the outdated stuff clearly.		* Mark the outdated stuff clearly. Date content in general with the last time it was reviewed.
	~~:''Agreed. What about a new wiki page listing what is '''really''' essential and should be put upfront? One approach could be to have the essential bits well written and presented~~ in static-ish CMS pages and stable PDFs and then move all the rest to this wiki ecosystem. As soon as new wiki content gets really good we could productize it and promote it.--[[User:qgil\|qgil]] 07:34, 2 June 2008 (UTC)''		* Improve the search (google?). Make search by section possible (developer documentation, user & community sections) - ideally allow inclusion of Bugzilla, the wiki and itT in search results.
	::''Don't create new wiki pages. The more pages you create, the more difficult it becomes to find and navigate stuff. Delete unused wiki pages instead. For documentation, you only need to have 1 (one) wiki page with ~~a list of all references, how-tos, and tutorials that apply to~~ the ~~current OS (4.x). If a document does not 100% apply but is still useful, mark~~ it as "partly deprecated". Create the same kind of pages for older OSes and link to them from the top of 4.x page, but make links small because this stuff is outdated and less important. [[User:fms\|fms]] 16:16, 2 June 2008 (UTC)''
	:::''I meant a new wiki page just for working purposes, like the other ones being created to work on the 100 days objectives". In this working-wiki-page we would propose and agree on the very essential pages and diocs that need to be promoted and stand alone, while all the rest would be moved wither to really secondary pages (i.e. "Disclaimers") or wiki pages easy to be edited and improved.--[[User:qgil\|qgil]] 08:57, 4 June 2008 (UTC)

	~~=== 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?).
	:''The plan is to have all the official HowTos and docs under a well structured ''Maemo Reference Guide''. Deadline: Diablo release. This reference guide would sit between the Quickstart Guide and the Training Materials. There were some fixes in the search ~~and should be working much better now.--[[User:qgil\|qgil]] 07:34~~, ~~2 June 2008 (UTC~~)''
	~~::''The website search has already been improved~~, ~~will add this~~ wiki ~~to the~~ search ~~too~~. ~~--[[User:xfade\|xfade]] 13:37, 2 June 2008 (UTC)''~~

	=== Get focused ===		=== 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.		* 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.~~		: Sounds like the things in the FAQ need to be in the porting guide --15:36, 1 October 2008 (UTC)
			* 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

			=== Build environment ===
	* Provide an example of simple build environment not relying on AutoConf and its friends. A single includable makefile should suffice, when used with SB2.		* 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 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.

			=== Longer-term goals ===

			These will not be part of the initial website revision, because they require more substantial changes to infrastructure

			* Make it possible for logged-in developers to annotate any place in the documentation. Link to annotations from documentation.
	* Clearly define what changes is made by default on gtk : like GtkTreeView with hidden header columns by default, or image-button off ...		* Clearly define what changes is made by default on gtk : like GtkTreeView with hidden header columns by default, or image-button off ...
	:''The idea is to have the sources of the official documentation here in this wiki. Users could add comments in the discussion pages, perhaps some users could get edit rights too. To be decided. The Nokia teams would updated their part of the documentation here and then all would be revised and conveniently package in PDF when a new stable release comes. So yes, we can put this in the 100 Days and then let's see how far we go in this timeframe.--[[User:qgil\|qgil]] 07:34, 2 June 2008 (UTC)''		:''The idea is to have the sources of the official documentation here in this wiki. Users could add comments in the discussion pages, perhaps some users could get edit rights too. To be decided. The Nokia teams would updated their part of the documentation here and then all would be revised and conveniently package in PDF when a new stable release comes. So yes, we can put this in the 100 Days and then let's see how far we go in this timeframe.--[[User:qgil\|qgil]] 07:34, 2 June 2008 (UTC)''

	~~=== Look towards the future ===~~
	* Define types of applications that will be useful on the Internet Tablet		* 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.		* 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.
	:''Good ideas, they can be pushed by Nokia and the community. The point about Javascript libs is imho more of a 2010 Agenda thing, though. I don't mean we wouldn't have anything before 2010, but 100 Days is just too tight. Besides, the work to be done goes beyond maemo.org.--[[User:qgil\|qgil]] 07:34, 2 June 2008 (UTC)''		:''Good ideas, they can be pushed by Nokia and the community. The point about Javascript libs is imho more of a 2010 Agenda thing, though. I don't mean we wouldn't have anything before 2010, but 100 Days is just too tight. Besides, the work to be done goes beyond maemo.org.--[[User:qgil\|qgil]] 07:34, 2 June 2008 (UTC)''
Line 41:		Line 46:
	''Related pages'':		''Related pages'':
	* [[Objective:Co-production_of_official_%26_community_documentation]] + [https://bugs.maemo.org/show_bug.cgi?id=101 Use the wiki for developer documentation]		* [[Objective:Co-production_of_official_%26_community_documentation]] + [https://bugs.maemo.org/show_bug.cgi?id=101 Use the wiki for developer documentation]

	~~== 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)

imported_>dneary: /* Brainstorm discussion */

2008-10-01T15:21:34Z

Brainstorm discussion

← Older revision		Revision as of 15:21, 1 October 2008
Line 38:		Line 38:

	See [[Task:Improving maemo.org/Development]]		See [[Task:Improving maemo.org/Development]]

	~~=== Brainstorm discussion ===~~

	~~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'':		''Related pages'':

imported_>dneary: /* Development */

2008-10-01T15:20:42Z

Development

@@ Line 37: / Line 37: @@
 === Development ===
-There is some discussion at [https://bugs.maemo.org/show_bug.cgi?id=3178 Developer documentation portal needs revision]
+See [[Task:Improving maemo.org/Development]]
 === Brainstorm discussion ===

imported_>dneary: /* Development */

2008-10-01T14:30:18Z

Development

← Older revision		Revision as of 14:30, 1 October 2008
Line 47:		Line 47:
	#* A guide to getting a Scratchbox environment up & running		#* A guide to getting a Scratchbox environment up & running
	#* Links to the various useful tools & Eclipse integration		#* Links to the various useful tools & Eclipse integration

	# "Documentation" or "Knowledge base" or whatever we want to call it will include:		# "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		#* The platform guide, including "Getting started", "Porting an app", and a guide to the components of the platform
Line 55:		Line 54:
	#* Links to relevant material in the wiki		#* Links to relevant material in the wiki
	#* Links to useful external resources & articles, and kudos for upstream projects		#* Links to useful external resources & articles, and kudos for upstream projects

	# "Reference" will include:		# "Reference" will include:
	#* Man pages - indexed and searchable		#* Man pages - indexed and searchable
	#* API docs for the platform - searchable!		#* API docs for the platform - searchable!

	# "Get help" will include:		# "Get help" will include:
	#* Reference to the developers mailing list (with an RSS feed of latest threads)		#* Reference to the developers mailing list (with an RSS feed of latest threads)
Line 69:		Line 66:

	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.		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.


	=== Brainstorm discussion ===		=== Brainstorm discussion ===

imported_>dneary: /* Development */

2008-10-01T14:29:47Z

Development

← Older revision		Revision as of 14:29, 1 October 2008
Line 36:		Line 36:

	=== Development ===		=== Development ===
	~~''(((The following items still need cleanup)))''~~

	There is some discussion at [https://bugs.maemo.org/show_bug.cgi?id=3178 Developer documentation portal needs revision]		There is some discussion at [https://bugs.maemo.org/show_bug.cgi?id=3178 Developer documentation portal needs revision]

	~~The following points were added during~~ the ~~brainstorm~~, ~~nobody has gone through:~~		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.

	~~1. Place references / howtos / tutorials onto one page so that developer does not need to click through several menus.~~		So all of the things in the "Development" section can be split along these lines:

	~~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~~".		# "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

	~~3. Make~~ it ~~possible for logged~~-~~in developers~~ to ~~annotate any place~~ in the ~~documentation. Link~~ to ~~annotations from documentation.~~		# "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
			#* 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

	~~4. Switch to SB2. SB1 is difficult to install~~ and ~~stays insulated from~~ the ~~rest of developer's system, making development complicated.~~		# "Reference" will include:
			#* Man pages - indexed and searchable
			#* API docs for the platform - searchable!

	~~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.~~		# "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)

	~~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~~.		The one thing I'm having some trouble with is figuring out where Source code will go (it is after all vital).

	~~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~~.		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.

	On a ~~related~~ note:
			=== Brainstorm discussion ===

			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'':
	* [[Objective:Co-production_of_official_%26_community_documentation]] + [https://bugs.maemo.org/show_bug.cgi?id=101 Use the wiki for developer documentation]		* [[Objective:Co-production_of_official_%26_community_documentation]] + [https://bugs.maemo.org/show_bug.cgi?id=101 Use the wiki for developer documentation]

imported_>qgil: /* Development */

2008-10-01T07:00:40Z

Development

← Older revision		Revision as of 07:00, 1 October 2008
Line 36:		Line 36:

	=== Development ===		=== Development ===
			''(((The following items still need cleanup)))''

			There is some discussion at [https://bugs.maemo.org/show_bug.cgi?id=3178 Developer documentation portal needs revision]

			The following points were added during the brainstorm, nobody has gone through:

	1. Place references / howtos / tutorials onto one page so that developer does not need to click through several menus.		1. Place references / howtos / tutorials onto one page so that developer does not need to click through several menus.
Line 50:		Line 55:

	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.		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.

			On a related note:
			* [[Objective:Co-production_of_official_%26_community_documentation]] + [https://bugs.maemo.org/show_bug.cgi?id=101 Use the wiki for developer documentation]

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

imported_>qgil: accepted

2008-07-25T08:54:22Z

accepted

← Older revision		Revision as of 08:54, 25 July 2008
Line 1:		Line 1:
	{{100Days agenda}}		{{100Days agenda}}
	{{task\|~~proposed~~}}		{{task\|accepted}}

	Connected to [[Task:Improving maemo.org]]		Connected to [[Task:Improving maemo.org]]

imported_>qgil: link to Task:Improving maemo.org

2008-07-01T12:46:33Z

link to Task:Improving maemo.org

← Older revision		Revision as of 12:46, 1 July 2008
Line 1:		Line 1:
	{{100Days agenda}}		{{100Days agenda}}
	{{task\|proposed}}		{{task\|proposed}}

			Connected to [[Task:Improving maemo.org]]

	Dress up the most important content, dump what is not relevant, handle via wiki the rest.		Dress up the most important content, dump what is not relevant, handle via wiki the rest.

imported_>qgil: task proposed

2008-07-01T12:45:51Z

task proposed

← Older revision		Revision as of 12:45, 1 July 2008
Line 1:		Line 1:
			{{100Days agenda}}
			{{task\|proposed}}

	Dress up the most important content, dump what is not relevant, handle via wiki the rest.		Dress up the most important content, dump what is not relevant, handle via wiki the rest.

imported_>qgil: Merging more content

2008-06-04T20:57:01Z

Merging more content

← Older revision		Revision as of 20:57, 4 June 2008
Line 45:		Line 45:

	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.		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.

			== 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)