SOC07 - art.gnome.org - Proposal

Abstract

The project is to develop version 3 of art.gnome.org(AGO).

The main objective of the AGO project is to be an artwork community server at users disposal. As such, Users are the ones who should decide what they want to see. They should have an user-centered experience and feel they are part of the community. Naturally artwork developers should also be encouraged to participate actively with their work. Without them there is no artwork. Thus, users should be able to comment and review developers works and consequently developers must be able to receive such feedback.

Benefits to the community

One of the key elements of communication is image and Gnome being one of the lead projects in Desktop environments plays a major role in such area. Users like to have a good look and feel in their desktops. If they do not like of what they see, they will certainly change whatever they feel is wrong. And this is where art.gnome.org plays its role in the community. Users like to have artwork at their disposal so they can change their system look and feel whenever they want. They do not like time-spending quests from page to page to find the perfect theme. AGO3 being a natural evolution of AGO, can become the only website they will ever need to customize their desktop.

Features

• Well documented and easily maintainable code
• Fresh new look and usable website experience
  • Accessibility and Web-standards Compliant
  • Theme-able
• Improved Artwork Administration
• Improved Artwork developers' Tools
• Support to create artwork contests
• Locales/languages Support
• Artwork
  • Complete Info
  • Improved developer actions
  • Improved user actions
  • Creation of Theme Sets
  • Rss/Atom feeds(comments, versions)
  • Categories
• User Management
• News system
• Content Management for sections like About and FAQ
• Friendly URL's
• An API(XML + RPC) so external applications may interact with the AGO3.

Redesigning art.gnome.org

The main rule: KISS(keep it sweet and simple). Aim for looks but with content in first place on the priority list.

Design an appealing UI without putting in risk accessibility and web-standards and never recurring to css hacks as solution to browsers' bugs.

Improve user experience for those who have javascript enabled with Ajax without losing functionality for those who do not.

With the help of a MVC approach a theme solution can be easily implemented. By that I mean users will be able to change the look of the website as they please based on the available templates.

User Management

System users fit into one of 5 categories: Visitors, Users, Developers, Moderators and Administrators.

• Visitors are the non registered Users. They will be able to search, browse and download the available artwork. Most of info associated to it(resources info, comments) will be also available.

• Users are registered users. They will be able to create artwork collections, customize the page, comment and rate submissions, suggest artwork tags, as well as to having access to a discuss board with feeds. By the time Users submit their first artwork piece they will become Developers.

• Developers are the natural evolution of Users. They will have the same rights of Users plus a few more. A series of development tools(change-log, version feeds, discuss board) will be at their disposal allowing them to maintain and manage their artwork efficiently. That includes moderating comments on their own artwork, managing artwork tags, uploading new versions, updating artwork thumbnails and action shots, etc.

• Moderators are elected Users who help in the task of managing the Hall of Fame. They will also be able to administer certain sections like FAQ, Documentation, Tools & Resources for example.

• Administrators are the 'Supreme Commanders' of AGO3. They have rights over everything and everyone. Only they can do User Management as well as editing the News Section.

This 5 categories can become much more flexible if implemented as an ACL(Action Control List) system. As so, they only are guides for the main Users of the System. Sub-user categories can be easily defined as needed.

Artwork Administration

Users are the ones who decide the future of artwork. A new artwork piece is by default in the New Artwork Section and will be moved to Added Artwork Section if it has a good acceptance by the community(positive rating). In case of negative rating it will be moved to Trash Section.

• Trash Section will be only visible to Developers. Artwork in Trash can suffer changes from their authors and then be re-applied to the New Artwork Section for new re-evaluation by the users.

• Added Artwork Section will contain every artwork with positive rating. If rating goes negative it will be automatically moved to Trash Section.

• Hall of Fame is the only manually moderated Artwork Section. Moderators/Adminstrators will decide based on Artwork ratings which ones should belong to the hall of fame. Only the best items should be included here; the ones with no bugs, with no problems installing via gnome tools. Moderators will have tools at their disposal to add and remove artwork from it.

• Every artwork piece will have a version history, as so, at every new version submission, old versions are included to the artwork archive. Unmaintained artwork can also be included in the archive by a moderator/administrator.

• 'Hall of Fame', Archive, Added Artwork and New Artwork are visible to visitors and Registered Users.

As was said before developers will have change-logs, discuss board, version history, tools which will allow them to efficiently maintain their artworks at their disposal.

Support for artwork contests

Creation of artwork contests is a way to boost users eagerness to create new artwork. The possibility to create contests is must-have feature in such system. Artwork submitted for a contest will follow special rules. A date will be set until which developers can submit their artwork piece. From that date on, users will be allowed to rate contests entries. When the contest ends results are shown and contests entries are accordingly archived or included in other sections.

Locales/Languages support

Support of various languages is a necessary feature. Automated process like artwork upload and configuration changes can be facilitated to users if shown in their mother tongue or at least in one they can understand. An approach using PHP gettext combined with Smarty Templates is an ideal solution for this problem. Since the language files will be external to the code, a call for translators can be made among the community to help in the process.

Artwork

Compiling what was said before, artwork will be reviewed and rated by users. Depending on ratings they will be moved to the trash or to 'Added Artwork' Section. An item in 'Added Artwork' can be moved to trash any time their rating becomes negative. Each artwork piece will have a complete profile where informations will be available related to image resolutions(if it is an Wallpaper), dependencies (in the case of themes), version, statistics(views, downloads, rating), artwork description as well as author instructions. They will have an Rss/Atom feed associated with comments or any changes in versions.

On artwork submission, if possible thumbnails are automatically generated and theme integrity is also checked. Developers should upload their own thumbnails depending on the category their artwork belongs to.

News System

There isn't much to say about this feature. This sections works like the current news section. Administrators will have rights to write, edit and remove posts.

User Management System

Implement an ACL system can make this administration rights much more flexible.

Content Management System

Sections like FAQ and About, which don't follow automated rules to their content, should be edited manually through a Simple Content Management System. The possibility to create new sections with this properties and include them in the menu will definitely exist. This sections will only be editable by Administrators or some not sot powerful user. The implementation of ACL in the User Management System can make this administrations rights much more flexible.

API (XML+RPC)

Creating an API will support the creation of third party applications based on the AGO3. It would benefit the community allowing anyone to create their own solution for browsing and downloading artwork. It is a great feature to help in the integration with Gnome Desktop.

The API would consist in a few simple methods that could be called to list categories, artwork from a certain category, artwork information.

-- API Specification --

• array category.list(void)

  list all categories in the Added Artwork Section

• int category.count(int id)

  return the number o artworks available in one category

• array category.get(int id,int start_index,int lim, int order)

  return an array lim elements (or less) with artwork ids, being the first element start_index or the next in order. The argument 'order' defines which is the order of the array(0=>'id ASC';1=>'id DESC';2=>'best rating',3=>'top downloads').

• array artwork.get(int id)

  returns an array with artwork info(title, category, link to thumbnail, description, etc).

Technical Details

All this project is intended to be implemented with an MVC(Model - View - Controller) development pattern. MVC separates logic from presentation which permits having cleaner code and web pages with less scripting. With this pattern the application is split into:

• Model represents data structure.

• View is the information presented to the user.

• Controller is the middle-man between the View and the Model. It process requests, gets information from the model and redirects it to the View.

Code Igniter

To help in the development of this project I'm considering using a PHP Framework , Code Igniter. It will help implement the MVC pattern, enable a much faster development by providing rich libraries for commonly needed tasks and allow me to focus on what really matters. Besides, cleaner code means easier maintainable code.

Easily maintainable and extensible documented code is an objective of the project. The possibility to change code without much difficulty is an essential feature of the system.

Priorities

Being this a not so simple system, priorities must be defined, and milestones set. To start the DB Schema must be defined to reflect every proposed feature as well as the bugs listed in the bugzilla. Once the database is delineated, we can start to code. Initially implement the User Management and the ACL System is the best approach since every other features will be based on what users can do and what they don't. By the time this base features are implemented, a few sketches to the web page layout must be already in production. Then the development of Artwork submission functionalities can give its firsts steps. In no time a system prototype will be up and running.

After this milestone features like News, CMS-dependent areas, RSS/Atom feeds will start being developed.
Along with it, the web page layout continues to be improved while new features are added.
After every minor and major feature being implemented, tested and fully functional just one thing is left to do, the API. Although it is the last feature to be implemented, its specification must be available since the beginning of the development process for maximum integration in the system.

Modules

Each section needs to have an modular approach so it becomes easier to add new sections to the system in the future as needed. Common dependencies can be implemented through the creation of libraries. For example, authentication library is a dependency of every module so they can implement Users rights in their functionalities. With this approach each module represents a different section in the website; libraries represent common module dependencies like Authentication. I must emphasize that each module still follows the MVC pattern to implement their functionalities.

Bio

I am an undergraduate computer science student at Coimbra's University in Portugal. Ever since I started using linux, Gnome desktop played a major role in my experience. The change certainly improved my productivity in the several project I later worked on.

Although I managed to have a great look n feel with Gnome Desktop, art.gnome.org not always had I what I wanted and that lead to the use of other resources. By then I couldn't do anything.

But now, I actually can. Since web development is my major field of work, developing art.gnome.org version 3 would be the perfect way to give back to the community some of my gratitude and improve AGO popularity.

Bruno Santos, March 2007