Have you heard the web design term “Mobile first”? It’s a concept where you start with the smallest screen size you want to deliver content to, and then you work your way up.
(This is part 3 in a series about how to build a Mobile first intranet. You can find part 1 here and part 2 here.)
Main
An intranet has several different page types/templates. Here are some of them:
- Homepage
- Navigation pages
- Content pages
- News pages
- Search results page
All page types have a global masthead, discussed in this blog post, and a global footer. But the main area on an intranet page is where the unique content for the page in question is placed.
In this blog post I design a content page. No matter what you call them—content pages, answer pages or service pages—this page type is the basic foundation for every intranet.
A content page should give a quick but great answer to the question the end-user has. You’ll need several hundred content pages on your intranet. A good content page has:
- H1 heading (only one!)
- Preamble (summary of the page)
- Action button
- Body text
- Sub-headings (optional)
- Fact box (optional)
- Further reading box (optional)
- Contact for further questions about the question (optional)
- Meta info about the page (e.g. facts owner, publicist, date updated, breadcrumb)
- Minor functions (e.g. save as a favourite, report an error, rating/was this page helpful?, print, share) (optional)
When designing a page for the mobile everything should be put in one column, like this.
Try it out live here! (Mockup for W375 points = iPhone 6/6s/7/8/X/Xs)
On this page you get:
- The page subject as the headline.
- A summary of what the page is about.
- An action button for applying for vacation. (End-users don’t want to just read about something, they have an action in mind.)
- Body text, a simple and straight-forward explanation of what vacation is and how it works. (You have X days every year, you can use it from April 1st, your manager approves your application…)
- A facts box. (Optional; if you need to state some facts.)
- Further reading. (Optional; in-depth content. Fact owners often want to link to laws and big documents. Here we can allow them to do this without sacrificing the simplicity of the page.)
- Contact info—not to a manager or the publicist, but to the person/function who can help you with you question (if the info on the page is not sufficient answer).
- Page metadata and minor functions—in this example when the page was updated, who is the facts owner (the person who vouch for the info on the page) and a link for reporting an error on the page.
Typeface and font sizes should be tested in actual devices in order to get the right balance on the page. This example uses Open sans as typeface with the following sizes:
- H1 (heading): Open sans 30 px
- H2 (sub-heading): Open sans 22 px
- H3 (sub-heading): Open sans 18 px (not shown on this page)
- Paragraph: Open sans 16 px
- Links: paragraph + Open sans semibold, #007BFF
- Metadata paragraph: Open sans 12 px
- Metadata links: metadata paragraph + Open sans semibold, #007BFF
You might think that 16 px for the paragraph sounds too big. In MS Word when creating a document, you often use 12 px or 11 px. But paper and a mobile web page is not the same thing, and you need to optimise for the device. Look at the metadata at the bottom of the page, which is in 12 px. Thats too small for paragraph text in my opinion.
(A god book about web typography is On Web Typography by Jason Santa Maria.)
Footer
At the bottom of every page you should have some kind of stop, a distinct indicator that “the page ends here”.
While it’s possible to have only a thick black line as footer or use the footer as an imprint (company address etc.), I prefer to put the section menu in the footer. (In desktop mode this can be a mega menu.) This way the end-user has a chance to try another page if the active page is not providing the right answer.
Test the whole content page here! (Mockup for W375 points = iPhone 6/6s/7/8/X/Xs)
***
Next post: The navigation page, the parent to the content page.
One thought on “The “mobile first” intranet (part 3)”