|Deletions are marked like this.||Additions are marked like this.|
|Line 7:||Line 7:|
|[[http://launchpad.net/diy-spreadubuntu|Launchpad project.]]||[[http://launchpad.net/spreadubuntu|Launchpad project.]]|
|Line 85:||Line 85:|
|We have a [[MarketingTeam/SpreadUbuntu/diy/Materials|material compilation page]] of our own. Add links and marketing material there.||We have a [[MarketingTeam/Projects/SpreadUbuntu/diy/Materials|material compilation page]] of our own. Add links and marketing material there.|
DIY project description and status
This will be diy.spreadubuntu.com. It will be a dynamic repository, enabling easy download, upload and translation. Front-end will be a Drupal-driven website, back-end will be Launchpad-driven.
We are coding this from scratch.
- discussing specs
- working on test server (contact pep if you need an access or code to be tested)
Task List:(don't hesitate to use...)
- check out for launchpadID registration restriction in drupal module... (launchpad as only openID provider)
- set up a complete list of the document types we accept, in order to clarify classification system
Specifications and features
We will use drupal and we plan on getting the site hosted at Canonical.
A key issue is to find out how the work flow in the site will be and implement blueprints in Launchpad that can target it. Please use our Idea Pool page to see the current ideas and propose new ones in this regard.
The Drupal frontend
- When the compilation is ready, we will set up a branch in Launchpad for all the material (Time for this to happen? - proposed 14th of August 2008)
Our drupal code or changes will be uploaded to the LP branch as well as the material once a day.
- The material will be organized in languages first, and secondly in regions/countries. (see further down for a classification system proposal)
- Drupal will use OpenID from Launchpad as the ONLY login option available (which means a Launchpad account for all users). Login WILL NOT be necessary for download of material, just for upload.
- The Drupal site will be used as an incubation site for material. t will have its own BZR branch in LP, pulled once a day.
- We will pull all materials from Launchpad once a day, after they are in "trunk" (which means they have passed the QA - Quality Assurance control)
- Trunk material from launchpad will be tagged in drupal in order to organize it and make it easy to access
Drupal comes with numerous modules and several versions. We may be able to use already existing modules with little or no modification to achieve our goals. Has anyone gone through the extensive list of modules yet to see what is availablle from drupal.org? No sense in re-inventing the wheel Also I suggest using drupal 5 rather than drupal 6 because it is less buggy, has more optional modules, and works with either php4 or php5. whereas drupal 6 pretty much requires php5. which may or may not be installed on the server we use to host the site. JohnBotscharow
LaunchPad & SU
- The Drupal code will be in Launchpad
- Every single document added to our database will be under the BZR version control system
- The Answer tracking system will help us gather questions on the material or request (translations, changes, corrections)
- Rosetta will help us with the translation of the material
- The marketing tag @ Brainstorm will be followed and added to our Answer tracker system in order to find relevant request wanted by users
- We will be working together with the Launchpad Team around the Drupal-LP OpenID integration (flacoste will most likely be our contact).
Right now the plan seems to be working together the main needs we have, formaulate them and start the implementation togethere with the LP Team by august. See the Drupal plugin blueprint @ LP for more information
Bazaar Upload can be a solution for the connection between SU and the bzr backend in LP
The idea is to save a lot of time in the process of searching for material. We want a site that is really helpful for the marketeer. If, once SU has grown big, s/he has to browse through thousands of archives before finding the ressource s/he was looking for, we won't have achieved our goal.
The system: (proposal)
A submitter comes to the site with marketing material. During the upload process, s/he has to specify a certain number of options. These can be:
- Type of material (we'll have to think of several categories; video, presentation, slide show, speech, logo, poster, flyer, etc...)
- Language (universal being an option if it's just a logo for example)
Submitting country, and if it's the case, submitting LoCo (adding some sort of upload-ticker on the map will give a sense of pride and add some spice)
- For which purpose it was created (conference, new release, fair, plain ubuntu-love, install party... maybe think of some good, common categories here...)
- Make a tickbox if it is specific to a certain version or variant of Ubuntu, in that case, enable specifying it per drop down menu or something...
- Target audience (?)
Drupal uses a sophisticated taxonomy module. All of the different variables (language, LoCo, etc.) listed above can be set up as separate taxonomies and be made mandatory fields to be completed, either by ticking off or, better yet, allwoing multiple selection, at the time of submission. We can use any given taxonomy in one or more areas of the site, e.g., uploads, marketing ideas, and the taxonomic tags become key words in the drupal site search, thus making it easier to find a specific piece of information. The design of the classification system is of extreme importance as it will determine the design of the site taxonomy. (After discussion, we will probably attach a meta file with all the information to every document/material)
On the other side, a marketeer browses SU can sort/filter the database by one or more of the previous criteria. In this way, material will be more easily found for given purposes, or for a given language, etc... (For obvious reasons, it will be part of the role of SU admins/controlers to make sure all submitted material is filed in the right categories.)
How to cope with the language problem: (proposal)
(You should have read the "Design" proposal, further down.)
Imagine the same document exists in 6 languages. A person filtering by the document type and purpose would see 6 entries for the same document. Rather pointless. So first I thought of having one entry per document, and not per document per language, but that disables the filtering by language in the list... still following me? So in my opinion, the best solution is to use the 'preferred languages' associated with ones launchpad profile, as we use openID, which will considerably reduce the number of redundant documents. Only appear the documents in english + the languages specified in LP. As a potential translator will have his preferred languages set in LP, he won't miss a document he's susceptible to translate.
What's the deal with the numbers? (see mockup further down) As you see, I put a serial number. There will be one per document, however many languages are associated with it. (So for example, if there are 3 versions of a document, the references will be: 4215-fr, 4215-ru and 4215-it.) The number is not random of course, we will have to analyse this in depth if we need any information in it, but at first sight, first number can be the type and the ones following serve only identification purposes. It allows quick designation of one specific document. If you look at the mockup you'll see several other criteria, the title will be different per language, the date also (last modified if corrections have been made), and the rating will be the same for every language.
It is important to have a nice Website we can be proud of! So add your proposals here! We're talking about the diy part only.
What will it look like?
You directly come upon a dynamic directory system, with columns for language, purpose it was created for, type, date, rating, submitting loco/country, ... (criteria still to be defined). A search box enables quick, direct filtering, clicking the column title sorts the list by a given criteria, and an advanced search allows to apply several filters to eliminate entries out of the list. The two parts of diy stand out: Browse and Upload, we want it to be easy and efficient! (See further down for more explanation) Here is a mockup I made on the Gimp this morning. I didn't take the time to do it nicely, I got it a little wrong with the columns, but you should understand what I have in mind. Even if SU is complicated in the functioning, it has to be simple and ergonomic for the end-user.
mpt from launchpad suggested using the whole page width as we have numerous columns, as well as considering whether some of the columns could be replaced by text in a secondary row for each item... So here come a second set of mock-ups, with slight variations in the search bar placement. In my opinion, the best is one, then two, then three.
What you see on the mockup is the main page, the 'Browse' section. The 'Upload' section should be very simple, the contributor just fills out a form, attaches his resource and he's done, the rest happens internally. But not surprises here, so let's come back to the browse section. When you click on a document, it is not directly downloaded, but you come to the document's "profile" page. Everything about the given document is gathered there. In the top left hand corner you have a little preview image (200*200 or something like that), you have a brief description, and the possibility to rate it and add comments (think of gnome-look concept). In this page, there can be more information and sorting criteria than displayed in the 'Browse' page. You would also have a big 'Translate' button, where you can translate the document into your language, this can forward to Rosetta, with the filter on the given document/language. Concerning languages I noticed that there might be a problem... please see the classification system proposal for more info. (if you don't see what this "profile" page would look like, just let me know and I'll draft a mockup. pep)
Recollecting Currently Existing Material
Find a collaboration framework with LoCos and other teams within the Ubuntu community.
A solution would be to contact every other team and ask them to implement a Marketing related page
Another way is to go around to LoCo wikis haunting for marketing material information sources
- Get and upload the material itself (not only the links) here in the wiki. See below for more information.
We have a material compilation page of our own. Add links and marketing material there.
SUGUI (spreadubuntu gui)
This is a Client side program for designers. The project driver is :meisok:, but he does undeerstand English if you drop him a line, so don't be afraid to do so if you are interested (English translation to follow...) Sugui es el nombre en clave para la aplicacion de acceso al stock de recursos desde nuestro escritorio, creada con la finalidad de facilitar el trabajo de diseñadores y colaboradores.
Leonov as our base?
Leonov should be fairly easy to integrate with other apps to show the contect stored in LP for the SU project, so designers can have easy and understandable access to the material, without having to learn the LP wheel
The Leonov devs are up to help us. Please write your ideas in their wiki: Leonov Ideas index. Leonov is planned to support a plug-in system. Hopefully through it we can add support for edition into the app for designers and other users, as well as uploading of changes made into the app.
- Interfaz en GTK 2.x
- Organizacion por tipo de contenidos, etiquetas y arbol clasico de directorios.
- Posibilidad de añadir material (?) (usando open ID de launchpad?)(Para esto se podrian crear varias categorias, para distinguir las modificaciones y las sustituciones de las nuevas aportaciones, habra items en los que resultara mas practico actualizarlos en vez de crear una copia igual pero con unas lineas cambiadas)
- Crear copia local del stock (con bzr?) (quizas poner esto como opcion?), actualizar copia local cada vez que se arranque la aplicacion (hacer esto tambien opcional?)
- marcadores (?)
- Traducir gui y manual al mayor numero de idiomas posibles.
- Integrar en los menus opciones para poder abrir los archivos directamente con la aplicacion correspondiente (a poder ser configurable, ya que cada persona usa su software preferido. Habria que evitar que al abrir directamente con la aplicacion un archivo, nos guarde los cambios sobre el archivo original sin avisar, quizas que automaticamente cree una copia sobre la cual trabajar...)
Se busca conseguir un interfaz de trabajo que nos proporcione una vision amplia de los contenidos, y al mismo tiempo ofrezca una forma de desplazamiento y navegacion rapida.