asciidoctor.org
asciidoctor.org copied to clipboard
asciidoctor
Create a wireframe for the new homepage
This is cool stuff!
Wireframe two attracts me because I love the Ecosystem block. It's a great launchpad to learn more about all the cool things Asciidoctor.
I really like the simplicity of the top nav as well. Just three things. Simple. Having the Discuss tab front-and-center is a big win. I wasn't fully aware of the Discuss area until @mojavelinux directed me to a post about six months into last year.
Having the Discuss tab front-and-center is a big win.
:+1: Getting people to more information faster should be the highest priority. The greatest feature of Asciidoctor is its community.
@stephenhay any thoughts you'd like to add about these wireframes regarding the new information layout for the asciidoctor.org landing page?
tl:dr; Oh god I'm not even sure if I should post this, but I'll just go ahead and do it, so apologies in advance for the length. Basically, the above wireframes look good. That said, they follow a familiar visual pattern, and I question whether this pattern supports the content as it should. I also question whether the content choices that have been made were intentional, or rather a side-effect of using this particular design pattern. I advocate asking and answering questions about content first, without visual representation, and working up from there.
Well, I hesitate to interject my thoughts on wireframes, since you're already far along, but you asked!
My own personal approach to wireframes is non-traditional in the sense that I advocate starting with no visual representation, but a simple list of content. I call this a content inventory, but it's different than what content strategists normally refer to as a content inventory, since it's not a huge spreadsheet of exiting content; it's a very simple list of content the should be on a given page or exist within a given component. We're talking large chunks here, such as "logo", "menu", "code sample", "output sample", "introduction", etc.
The list for, say, a home page would contain the content chunks that absolutely must be on the home page. As in: if it's not there, this page (or screen, or component) is not doing its primary job.
Once you've thought about this from a strictly content point of view (not even worrying about visual for now), you can rearrange this list in order of importance. As in, "if I had to read this page from top to bottom in linear fashion, what must come first?" You'll note that you're automatically and somewhat sneakily preparing content for the smallest screens this way.
Once you're convinced that this is the content you absolutely need, in this particular linear order, then comes the move to "content reference wireframes", aka wireframes the way we used to make them. They're pretty much gray box wireframes: You take each item in your list and turn it into a block. Then you guesstimate the height of this block based on your knowledge of what that content in your inventory will actually be. And you're doing this while emulating a smaller screen, so it's still a linear representation. Once this is done (I do all this in HTML/CSS), you expand your browser window, again simply estimating at what width this linear layout will need to change into something different, because of text becoming too wide, etc. You don't have to be exact about these estimations, as this is just a thinking tool.
When reworking the layout of the boxes at these breakpoints (which are always based on when the content dictates a change and never based on device screen sizes), you keep asking yourself if the changes you are making still coincide with your original choices regarding content: am I still treating this as the most important thing? Does this layout support how these two chunks of content relate to one another?
What will later be placed in these boxes, as far as exact content, does not matter at this point. These content reference wireframes in HTML/CSS can slowly increase in fidelity, actually becoming the finished design comp. As you have more information, there is constant tweaking going on. Since you've started your wireframe as mobile-first responsive, you get feedback from every browser and every device you use to view it, and can adjust accordingly.
I know this is not what you asked me. And it could be that the heavy content questions have already been answered and that you're already visually designing. Due to my publicized arguments for this content-first approach, I simply feel obligated to explain whenever I'm asked to view anyone's wireframes. The approach outlined above primes everyone for responsive, focuses on the hard content questions (how important is community related to [x]?) and starts dealing with those questions without any visual representation. The visual representation then follows suit, and is, throughout the breakpoints, continually tested against the original decisions about the content.
Here's an example of some of the thinking I might have when looking at the first wireframe above. I've probably done commercial client work too long, but I want to instantly know what this thing is, and what can it do for me. A video is great, but what if I can't or don't have time to watch it? In that sense (and I don't mean to be overly critical), a catchy tagline is fun, but I still want to know what I need to know. If the tagline doesn't tell me, then I personally would consider how I can integrate the two. Download is important, but I will only do that once I know what I'm downloading. I don't know that based on the short copy (depending on the short copy, obviously). So does Download deserve to be the most prominent thing on the page? Or does short copy need to be altered considering that I'm promoting Download as the primary purpose or action of this page? Is video not simply one particular method of conveying what Asciidoctor is? If so, is it useful to support that with non-video content? Maybe even have video be the support to the non-video content? Etc. So now we have a visual representation, but I'm asking fundamental questions that might mean going back to the drawing board in some cases. Starting with these questions and constantly testing against their answers often leads to very different, more effective, and sometimes exciting choices that might even go against the status quo of those projects/clients/products that start with visuals.
If you have the time after spending the year it took to read this, You can see the gist of the above approach via these slides: http://www.slideshare.net/stephenhay/mobilism2012
I must make perfectly clear, BTW, that I don't intend my comment above as negative in any sense, and I appreciate the work that I'm sure has gone into the wireframes! So please regard my comment as an attempt to look at the wireframing process from a slightly different angle, to perhaps add some thinking to the existing great thinking that's been done here.
imo, the Ecosystem is a great feature, but unless you already know the ecosystem, it is hard to understand the context of what is what. If possible, can they be grouped by categories/tags?
