Skip to content
This repository has been archived by the owner on Oct 10, 2017. It is now read-only.

Website nav #77

Open
jamesplease opened this issue Jun 2, 2014 · 5 comments
Open

Website nav #77

jamesplease opened this issue Jun 2, 2014 · 5 comments

Comments

@jamesplease
Copy link
Member

I think we would all agree that moving away from the one-page design is a necessary change for us as we begin work to expand the site. Here's what I think our nav should look like:

Home - The main about page. Much of what we have now can stay on the home page, I think. Just a general overview of what Marionette is.

Guides - All of our guides. Getting started would go here, along with guides on views, Marionette best practices, architecture solutions, and so on.

API - The API, which I think is separate from the guides.

Blog - The official blog. We can write about releases, general tips or strategies, or really, whatever we want here. This lets people know that there's an active core behind the project.

Download - Download every version and every type of build. Also download the individual pieces, or make a custom build.

Community - I'm not sure if we would want a single section for this, but I want a place where we can have information about meetups, and also a place for plugins and so on. One day I can see us having a Curated Backbone Plugins List, where we approve and help maintain popular Backbone plugins. This would give us a stronger footing in the greater backbone community, and help us stand out as an authority on Backbone, which is where I want us to be.

What do y'all think?

@samccone
Copy link
Member

samccone commented Jun 2, 2014

who is using should be in the top slot

@jamesplease
Copy link
Member Author

I agree that we should highlight that on the main page, for users becoming acquainted with Marionette, but I don't think it belongs in the top nav. Do you, @samccone?

@samccone
Copy link
Member

samccone commented Jun 2, 2014

I do, it was really the top question i got this last week, "who is using marionette"

It is a validation for investing into learning this tool.

@chiefGui
Copy link

I think Marionette.js is a delicate library. Nowadays, the way you introduce it to the world is shaped in an advanced and subjetive way – understand "subjective" such as "you, developers, are already used to working with Backbone, etc, etc, then doesn't need deeper details on how to get Marionette working".

Let me explain a little bit more: I am a good JavaScript developer. I am also a good UI/UX designer. Period.

Backbone and Marionette are awesome platforms which improve the way we shape our applications, but for whom that want to bootstrap their apps with a good structure on the top of Backbone + Marionette, they go against conceptual issues of what's the difference between Backbone and Marionette – what you can and can't do.

I think Marionette should be simpler even for those who are starting right now. There are lots of Marionette.js' sample applications around the web which contradicts themselves because it all shows a different way of "the right way".

I caught by some traps that made me refactor my application lots of times because I've never know what's the best way to perform something. I know that "the best way" is something relative, but we need to teach most ways as possible to solve an isolated and specific problem.

Of course, Marionette.js is a bunch of tools you give freely and can't deal with all world's problems – neither God could –, but I felt some difficulties on my beginning which could be resolved with some simple explanations and a brighter readability design. I even think we can achieve readability issues with a smart thinking of typography.

What I'm talking about is the reestructuring of the www navigation thinking. IMO, you have to focus on design readability and usability – a suggestion is grouping into one thing "APIs" and "Guides" as was previously proposed – and then, magically, you have a huge percentage of beginners-questions solved at once.

TL;DR

The Marionette.js' biggest problem isn't on the documentation itself. I think the way the information is connected, distributed and designed is wrong – it's "boring" to read the documentation and try to find the right solution for your problems thanks to usability issues. Difficulties and lazyness are friends – mainly in this programming world where people just want "things done".

@chiefGui
Copy link

And I agree with @samccone. Cases of use, although doesn't mean quality, it's a very good parameter to a company – especially a company! – to get started with something new. You know, companies around the world are, most of times, restricted to new things and we have to show them that we can make them go further.

I will make some conceptual prototypes in Photoshop and give you a sneak of what I think could be the next big thing on Marionette's-www reality.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants