Re: [GMG-Devel] Clarifying site's organisation

[Tumulte Dogma]

I really have to  stress the fact that mediagoblin is complex for the
new comer, and that those new-comers are of different profiles.

I mean : you have a lot to say, and what you have to say differs from a
profile to another. Let's give you some exemple : 

- I'm an artist, is it what I need to display my work ? If yes, why
should I prefer that over a flickr/youtube/whatever... ? If I choose
that, should I go to a preinstalled mediagoblin, or get my own ? Do I
have the skills ?

- I'm a art manager, I want to build a website to display the work of my
artists, can I manage several accounts ? How about right management ?

- I'm a coder, I want to build a software that is loosely the same thing
that media goblin ? What language is used ? is it easily hackable ? Is
it documented ? Is it extendable ? Is there a community, how-tos, docs ?

- I like this project, I want to help... how can I ?

- I'm a curious person... what the hell is that ? What the hell is
GNU ???!!!

Of course, it's impossible to answer all those questions in one page !
But you have to give a clear overview of what's possible (or, at least
hints that it's possible and they should dig further)

Since it's not only a binary package you're giving there but a rather
complexe piece of software that target a wide variety of persons, I
don't think it's relevant to go for the simple CTA design.

The main goal of my mock up was to give you an example of a design that
would allow experienced users to get what they want right away (it's all
above the floating line for them) while giving noobs enough informations
to decide if the soft is for them without having to leave the page. For
that reason, don't be afraid to have a huge webpage, since it's
unobtrusive ! It's important that if someone leaves the page - say for
the doc- he won't get frustrated too find informations irrelevant for
him, thus the idea of link selections. If you're afraid of
maintainability, it shoudn't be much of a problem if your doc is well
organized. For instance : The beginner's guide might change, but it'll
remain in the same place.

Here's a rather extreme example : http://www.lemonde.fr/ : everything is
available right away, but there's 11000px of informations below !

To sum this up : don't rely on a simple CTA design, you have too much to
say, and it will either be drown among all the information, either not
be there at all.

Le samedi 26 janvier 2013 à 15:59 +0100, Jef van Schendel a écrit :
> Hi,
> 
> I'm not the one to talk to regarding the docs/wiki separation, so I
> will skip that part of your mail. But I have been working on a
> redesign for the MediaGoblin homepage so I will comment on that.
> 
> For reference, this is the latest mockup:
> http://schendje.fedorapeople.org/goblin/homepage/wireframe3.png
> And this is a version with notes:
> http://schendje.fedorapeople.org/goblin/homepage/layout_explained.png
> 
> 
> 2013/1/25 Tumulte Dogma <address@hidden>:
> > - The wiki is not the place to dispatch users, the main page is.
> 
> You used the word "dispatch" a few times, but I am unsure as to what
> you mean by it. Are you talking about directing visitors to the
> appropriate locations?
> 
> 
> > - Any information on where to contribute, fill a bug, find info, help...
> > should be on the main page.
> 
> I agree. Looking at these one by one:
> 
>  - Contributing. As you can see I've put the "Get involved" button in
> the "Our community" section, as well as links to IRC, the mailing list
> and other ways to contact the developers.
> 
>  - Fill a bug. The mockup contains a link to the bug tracker, so this
> is also included, but it might be good to have a link in the actual
> MediaGoblin software as well.
> 
>  - Find info. The homepage itself should contain enough information
> about MediaGoblin, the software, as well the MediaGoblin project and
> community. I believe my mockup satisfied this as well, though it is
> (intentionally) heavy on the software-side.
> 
>  - Help. Depends on what you mean by help, but if it is help as in
> "how do I get this thing to work", this is (or should) all be included
> in the documentation. The homepage has the "Use MediaGoblin" call to
> action, which links to the docs. However, it might be good to add a
> "documentation" link separately.
> 
> 
> > Additionally, since I want to put so much in the main page, I've made a
> > quick and dirty sketch of a One Page App design for mediagoblin.org.
> 
> Thanks for taking the trouble to include a mockup! That's really helpful.
> 
> However, I believe it is starting to contain too much info. For
> instance, having a spot in the layout for "Contributing" is great, but
> we don't have to describe all the ways to contribute right away.
> Instead, we can show that it's an option for the people who are
> interested, after which they can choose to visit a page with more
> info.
> 
> Likewise, the "Learn" section has useful sections, such as how to
> install and how to configure MediaGoblin. But I think displaying such
> a large amount of information right away is counterproductive and we
> should simply link to the docs instead. Keep in mind that adding more
> content doesn't just cost more pixels, but also requires curation and
> maintainance. A wiki page is much easier to update than the project
> homepage. ("How to code for it", by the way, should be placed under
> "Contribute").
> 
> 
> In conclusion, both mockups share a lot of ideas, that's interesting.
> There are *a lot* of aspects to the MediaGoblin project so the trick
> is include everything that's important in an orderly and clear
> fashion, which is why I think we need to keep things simple.
> 
> I think my mockup could be improved by adding some of your ideas, namely:
> 
>  - Adding a more visible link to the documentation.
>  - Finding a place for the "donate" button, because I had not included it yet.
> 
> Jef