spreadubuntu team mailing list archive

[Pierre Vorhagen <pvorhagen@xxxxxxxxx>]

Hi,

I am sick of waiting for tings to happen, so I'll take Onnos list of 
questions with some modifications and start writing my view on things.
Important: This is how I've got it in mind for the moment, I am 
completely open to discussion, and I hope my answers will evolve. Don't 
hesitate to comment, correct or write your own set of answers if you've 
got a completely different point-of-view!

This is a long e-mail, I know ;-)

> * What kind of services will the diy site offer, that is for
> example, upload, download, search, version control, etc.

- Imo, diy.su.com offers mainly a download and an upload section.
- Upload is a simple section, you get straight on an Upload page, where 
you enter all information we need and click "Submit", that's it.
- Download gives us a great list of documents, one per row, with several 
columns to sort by. When you click on a document, you come to a 
gnome-look type "profile-page" relevant to the document, with a short 
presentation, version, available languages, maybe a 200*200 screenshot, 
the ability to read and post comments, and a big "Translate" button. 
(This button would re-direct to launchpad I suppose) Also, you can give 
a rating to a document.
- As you can see on my mock-up, there is a quick filter, enabling to 
immediately filter the list of documents below (in the Download section 
ofc) but as this is relatively limited, you can access an "Advanced 
Search" page, by clicking on the link. On that advanced search page, you 
can search per multiple criteria, using OR/AND/XOR/NOT between 
keywords... well, an advanced search.
- There is openID registration/login.
- Also the diy site links back to a couple of sites of our choice. 
(ubuntuvideo.com for one, they are the video repository)
- And that's it! Imho, and mpt from Launchpad was of the same opinion, 
more functionality just makes the site less usable and efficient. We 
have to go straight to the essence of our service to be competent.

> * What information is required for the static site?

- You're talking about the Site part, not the diy part. To be honest, I 
don't care for the moment, we fixed our focus on diy for now.

> * How big will the documents be that we're going to offer?

- This leads us to another point I thought about:

* Which *type* of documents do we support?

- Imo, we have to set someone on analysing the common document-types. I 
suppose all image files, all OOo files, vector graphics of course, 
anything else? Sound files? (podcasts, speeches...)

> * What kind of load are we expecting?

- I am over-questioned there as I have no idea of how many people will 
be interested in our content. But if we pull this through properly, I 
think we can count with a relatively big load, if we really are the 
central resource.

> * How much disk-space are we going to need?

- That will depend on the type of files we accept, and the size limits 
we define for each type of document.

> * How much band-width?

- This question bothered me too some time ago. Someone suggested to pull 
everything over from launchpad once a day. Imo, that is useless 
transferring. It would be more effective and bandwidth saving to do a 
simple synchronisation, pulling over to diy only modified documents. For 
the actual calculation, we need to know how many documents and of which 
size we're awaiting.

> * Who will be able to do what to the site?

- Good point. As I see things, there will be 4 different status'.
- First: the user without log-in: he can simply download documents. If 
he wants to translate he'll need a log-in anyway to work in launchpad, 
and if he's uploading it means that he's probably an active Ubuntero or 
somehow interested in making Ubuntu progress, so he'll probably already 
have a LP log-in or be pleased to get one. He also can't comment on 
documents. This gives us a good control on origin of incoming documents, 
and reduces spam.
- Second: the logged user: he is the real user of the site, he can 
download, upload, translate and comment.
- Third: SU moderators: they are responsible for making sure there is no 
spam in the comments, for checking all incoming documents before 
synchronisation, making sure the tags are correctly applied (not tag a 
presentation as "flyer" for instance), supervising translations...
    If this turns out to be too much work, we can always divide this 
group into one moderation group responsible for comments and tags, and 
one responsible for translation for example...
- Fourth: this is a background role, admins: This will be us I suppose, 
or at least the people behind the actual site and infrastructure, 
although they can also be part of the moderators, they make sure there 
are no technical problems concerning diy, synchronisations, etc...

> * What kind of access controls will there be?

- Access controls? Well there is openID... I'm not sure what you mean, I 
hope I answered this question above.

> * Which languages will we support?

- Very good point too, I already thought about this too. We have to 
respect that numerous people don't speak English.
- The un-logged user, sees the site in his main browser language or in 
English (still to be discussed).
- The logged user sees the language in his primary preferred language in 
launchpad. (huh? I know, there is no primary preferred language in 
launchpad, you can only select a list of languages in no order, I filed 
a bug about this here just yesterday, take a look: 
<https://bugs.edge.launchpad.net/launchpad/+bug/249111>)
   If this primary preferred language business turns out not to be 
possible, I suggest we use English, if it is in the users preferred 
language list, and his browser language if English is not in the list. 
(We have no way of seeing which language he prefers if he's got 
Portuguese and Spanish for example.)

> * What interface elements will need to be translated?

- Everything. The elements describing a document and so on are 
translated with the document itself, diy will be completely translated. 
At least I'd like it to be.

> * Who will be the audience for this site and what requirements do
> they have?

- Audience is for one part the active Ubuntero or marketeer, this is our 
primary target, and for two it is the normal user, that came onto diy 
through the Site part, willing to spread his new OS around him.
- For the first type, they need a straight-forward infrastructure, that 
is mostly effective, and well integrated with launchpad. They are 
probably used to contributing and don't want useless clicking. It is 
mainly in that optic I designed the mock-ups and I think it's the most 
important one.
- For the second type of user, the documents need to be intuitively 
found, that is, if he's got no idea what exists, he can easily come 
across something of great quality and use... maybe think about 
optimizing the automatic search filter to sort first by the highest 
rated or something...

> * Where will we source our initial material?

- A team will have to be set-up to go out and seek for it, we already 
have a nice collection on the Marketing team and on the SU wiki. Also, 
will we call the LoCo teams to submit all their material.

> * What kind of version control will we use for the site itself?

- I suggest keeping the site code in launchpad and using bazaar. I'm not 
yet completely familiar with this but I'm trying to get the grips with 
its functioning...


I described how I saw the classification system and how I would treat 
documents in different languages in the wiki, I will put it in here for 
additional information:

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 first mock-up I made) 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.


Now, to a couple of important questions of my own I would like to be 
precised: How exactly will diy and launchpad work together? What will a 
document be in LP? (a project? oO)


That's about it for now, sorry this got a bit long, but we've got to get 
into the business now. Don't hesitate to discuss and add to what I wrote 
above.

have a nice day,
Pierre