The network site enables staff and (in the future) network leaders to create simple landing pages. We're using these currently for opportunities like leadership training, accessed either via features on the homepage or external incoming links.
As the site becomes home to more of our initiatives, we'll need to enable some simple multipage functionality.
What does this look like?
User creates 3-4 simple pages. Each page then gives the option to link to one or more existing pages in the CMS. These links are gathered into a pre-defined navigation component on the page.
Quick naive mockup

Consider a few use cases that current require their own site:
Edit: adding item Fellow or network member initiative. Funded or personal project. Local campaign. Note! We should design to capture 80% of the most common scenarios. MVP. We don't need to design for any one specific use case.
design for mobile and desktop from the start...
Matthew, I took a look at the existing sites of the examples you mentioned above and placed them in a scale of complexity (I find this scale a bit subjective, let me know if you agree with the order I placed there):

I think these nav components would work well for simple sites (the ones listed in "less complexity").
Here are the wireframes:
V1 DESKTOP: https://invis.io/ESBKWC9UT#/232047968_V1-DESKTOP__Network-Full_Site
V1 MOBILE: https://invis.io/QNBKWGKSU#/232042199_MOBILE__Network-Full-Site-Mode1
V2 DESKTOP: https://invis.io/HSBKWIPTV#/232242145_V2-DESKTOP__Network-Full-Site-Page1
V2 MOBILE: https://invis.io/N2BKWJ6H3#/232056414_V2_MOBILE__Network-Full-Site-Mode1
In all wireframes the link for "page # 2" is clickable
Thanks. Do you have a preference? I'd like to introduce one pattern only, v1 or v2.
I think v1 is more flexible and less ambiguous. It's also useful for simpler, less content. Example: fellow has a page about their project with some support pages or resources. A list of pages feels right, a horizontal nav could feel wrong. v1 can also handle longer page titles by net members.
Is it a common pattern to collect subnav into a drop-down menu on mobile? Any other patterns worth considering? I think it's more friendly and accessible than the slide sideways menu in v2.
What do you think we should do next? Test this wireframe against a simpler and a more complex site? I'd like to see if MozFest could live here. Let's test without creating extensive work. Maybe a collage cutting up screenshots of existing sites? Any other ideas?
Hey Matthew!
I agree with you that V1 is more flexible and clear. I prefer the left aligned section as a secondary menu for the same reasons you pointed out above. To add to that, I think that this structure also helps to differentiate primary and secondary menu.
Answering your question if this is a common pattern: yes. I collected some examples here: https://docs.google.com/a/mozilla.com/presentation/d/114IrxFavXcTD3JRFRbagP9HP23ydr-icyxwaSnKcoZY/edit?usp=sharing
I agree that it is worth to investigate other options. I'll spend some time on that investigation and add to the benchmark. If you've seen any pattern you like please let me know and I'll add it to the slides.
I like the idea of testing it against a simple and complex site to have a better feeling of it.
Although I think Mozfest should live as a standalone site it doesn't hurt to do a quick experiment to see how it looks like. For the simpler site, do you have any suggestions? I feel NFS is a simple one but if you have an even simpler one in mind, please let me know.
I want to do a clickable rough prototype with a collage so we can see how the experience feels from a user standpoint. What do you think?
Great. Let's proceed with v1, drop v2.
Sub-nav:
Menu â–½ works well. I don't think you need to do a big investigation. I like Slack's implementation the best. User case:
If it's useful to look at more examples, I would add two active examples from the Learning site:
I understand that this ticket is about looking at the IA implications of incorporating this content into the Network site, and I think these are good candidates for exploring that further. (On the MCW side, It would also be useful to consider how we promote the quarterly MCWs on the site. Do they belong under "Events" or "Trainings" on the Support page, for example?)
Yes, and yes. I think the pages for both of these things become simpler and focused on general info, and their active content gets integrated with News, Get Involved, Projects. For people interested in online privacy, Gigabit, Austin, and MCW, are arbitrary boundaries.
As you're hinting, I'd wager that there are more people interested in the Aug 10th discussion on Online Safety Resources for Learners than the people who think they belong within the Mozilla Curriculum Workshop.
Looking at these examples, I think the page design remains simple, while we take a hard look at Get Involved and how it will need to grow to better serve events.
"Mozilla Curriculum Workshop (MCW)" page has an interesting design challenge I didn't think about yet: the Etherpad is attached to the page. I'll keep this in mind for the future, as we evolve those pages. Thanks for bringing up those examples, Hannah.
the Etherpad is attached to the page
We won't support that at this stage. We can, however, see if the CMS offers buttons in the wysiwyg so that people can include a prominent link to their pads.
Users can insert an iframe for youtube videos and other rich content. If there's way to do that with pads, that's great. The cost otherwise outweighs the benefit.
Just a note that it was considered a key requirement when we created the page to have the video and the etherpad on the same screen. Maybe that's changed, but probably worth a discussion with stakeholders.
We can file that in a new ticket. The scope here is to look at the simplest solution that serves a broad set of use cases, for internal initiatives and use by the network. We have a lot more to build out in basic CMS functionality before we start building unique features like that.
Here are the 2 models that cover the 2 scenarios highlighted above.
Please notice that they are only for structure purpose (I didn't apply style to them yet, so they are close to wireframes). They were built to be seen at desktop size and mobile (less than 375px).
SIMPLE MODEL (user case number 1 highlighted my Matthew above)
https://taisdesouzalessa.github.io/simple-model/
COMPLEX MODEL (user case number 2)
https://taisdesouzalessa.github.io/complex-model/
Next step: apply UI and styling to those models. I will open a new ticket for that.
cc: @xmatthewx