Just setting this up as an issue as suggested:

I’ve built a little jQuery function to identify links on a page against a list of subdomains. This came about last week when the CMS needed to be taken offline for a couple of hours. Chaz built the outage page using the new templates, but had to create his own injection so that he could manually go through and indicate which of the links in the University sitemap were offline as well.

This function allows you to centrally enter a list of domains and subdomains that will then show the user that a particular link is not available.

My intention was to add this function to the GitHub repo and commit it as a pull request, but I have no idea which file from the repo I should be changing, or even if a jQuery function will work in the templates (I haven’t been able to test it locally because we still haven’t figured out the issue with the Ruby gems on my machine).

Anyway, here’s the function: https://gist.github.com/tomstringer/5ef0652c715447f9d5c8

Neil said:

Good question. Prob a good case for a new GitHub issue or PR so we can talk about it. Some things I would discuss: how would the users interaction with the site change with a link labeled as offline? Is the list globally set or per site? How would this work with JS asset caching? etc.

As far as adding it, we’re currently missing the documentation on this. I’m guessing it would be a component if its per site addition, or injection if it is a global feature.

Paul said:

Definitely a good one to document and discuss. For example, we don't actually use jquery (especially in injection) as its too slow and not as cross browser compatible any more.

How do I get my local fork up-to-date with the work that's been done since I originally forked it?

I'm using the Github app and syncing doesn't work because it's trying to sync with my local fork, rather than your original…

One thing that the uni does pretty terribly is attribute content to it's creators. In particular photography, but also snippets of text, cuts of video etc.

I'm thinking it'd be great to meet with the copyright office to find out what we are actually legally required to do and then finding a way to bake this into the templates so that people have to actively remove copyright notices rather than simply fill them out.

A large part of making this work is about making it so that the attribution isn't really ugly or in-your-face but still easily findable.

Ugly eg

There are also issues that I'd like to clarify. For example, if I'm on a page showing a lot of images (eg. an events index or a story index), does attribution need to be given at each image? Or only once you click through to the story itself.

Any thoughts?

At the moment, hover state means that button becomes less prominent when you hover over it, instead of more prominent as I would expect.

Given this site uses a number of elements that are not widely used across the University (.slim, .md etc), additional instructions will be required for setting up the local development environment for contributors. I think you'll find most people you want to contribute will have as little knowledge as me (if not even less).

I've tried following the instructions in the README.md file, but the bundle install and execute commands require something else - are these Ruby commands?

Or is the intention that most of us will only work in markdown and won't see the finished product until its published?

Wondering if someone might be able to help.

I've managed to set up the local dev environment on my machine and can view the site at localhost:3000

Everything was working ok, but there now seems to be a problem displaying the markdown pages (see error screen attached). Any ideas?

An idea for any video styles we create. We should encourage transcriptions (for SEO) and Captions (for accessibility).

This could be an accordion from a small centred link which expands to show the transcript for the video.

Perhaps we could use a selector box as per Gov to make these work nicely on mobile.

Moving this issue over to templates.

Ref https://github.com/marcom-unimelb/pursuit/issues/6

Currently, when clicking on a tab, it will scroll the page to the top of the tabs, but since the introduction of the fixed header, there should be a ~40px top offset so the text in the tabs is not obscured.

Currently:

Should be:

Just looking for a more in-depth explanation of the uom typefaces and noticed that we will need to update this at some point (in particular the hex colours).

http://marketing.unimelb.edu.au/branding/uom/logos-devices-and-typefaces.html

@herrweis - is the $navy colour a better translation of uni-blue?

The accordion cannot be activated using the keyboard

In the University site map the last child in the .quicklinks drops down/up when browser window is resized.

Screencast
http://cloud.chaz.ink/0Z3f3P460O38

Probably one @waitingallday could answer with a modified version of existing gist.

CALL TO ACTION button lacks sufficient contrast (#FFFFFF:#349AEC = 3.01:1)
Increase contrast ratio to 4.5:1

This is a big one for us to consider.

How do we ensure that people using older version of the templates get access to changes made globally. Eg. scenario. If we were asked to change the font in two years, and we had versions 1, 2 and 3 being used in production, we could update all three versions at once.

Something large for the way that our templates repo is structured.

@waitingallday suggested sub-modules.

We need to find a way that lets us denote whether a feature is supported by a particular CMS or not and when it might be coming / available.

The accordion titles cannot be selected using a keyboard.
Solution: add a tabindex value of zero to each accordion title

Also might be worth noting that subjects that require lots of focus should be along the top of the image.

In the current templates, we have the concept of a local footer. In this local footer often people put information about who to contact if something is wrong or incorrect, or who has authorised the site.

This is also where we often put general contact details for a site and I have even seen this space used as a secondary mega-footer.

Often, this info is out of date and not really that useful. That said, it does seem to be a requirement as it's used to do much of our site classification and ownership.

As I see it, there are several possible solutions.

1. We provide a local footer component
2. We provide a better alternative for people to use that covers all these uses (eg. a "site metadata type link that opens a small modal with this info).
3. We find a way to integrate this into the local navigation so that it can be made accessible, but not always visible.

Any thoughts?

The selector listing styles have been hardcoded into Bespoke, but should be centralised. This is the code we're using:

[role="main"] {
  @include breakpoint(desktop) {
    .selector-listing-3 {
      @include rem(padding, 50px 0);
      display: table;
      height: 100%;
      margin: 0 auto;
      table-layout : fixed;

      &::before,
      &::after {
        display: none;
      }

      li {
        background-color: transparent;
        display: table-cell;
        float: none;
        height: 100%;
        margin: 0;
        padding-left: 1%;
        padding-right: 1%;
        vertical-align: top;
        width: auto;
      }

      a {
        @include rem(max-width, 350px);
        @include rem(min-height, 400px);
        @include rem(padding, 0 35px 0 35px);
        background-color: #366996;
        height: 100%;
        margin: 0 auto;
        position: relative;
      }

      p {
        @include rem(padding, 20px 0 100px 0);
        margin: 0;
      }

      strong {
        margin: 0;
        padding: 0;
      }

      .button-small {

      }
    }
  }
}

This is pretty high priority because at the moment, the only way to close the nav on a mobile once it is opened is to go back.

Putting this here to see if you agree.

I was about to start writing the documentation for the colours to try and explain why we set a palette of colours that we expect people to use.

I started to use the example that "Green" would convert visitors better as a CTA than other colours and that's why we recommend it, when I realised that I should probably do some research. Looking into articles like this, it turns out that red converts better than green in this case.

As I see it there are two reasons that we set colours in the templates.

• We set colours to ensure consistency of user experience and brand-compatibility (eg. the #003366 problem.
• We set colours to make it so that people get the most possible utility from their sites.

This means that we should be actively improving those components that are used the most frequently in order to make them work better. Buttons would be an example.

I think that buttons should be created for a purpose and we should explain the correct way to use each sort of button. Eg. CTA buttons are different from "read more" buttons.

We should maintain the design flexibility to allow people to globally change, for example, the colour of a CTA button if they can demonstrate that Red works better than green as this allows us to improve the whole site at once.

So.

Colours > several set colours (eg. $navy, $darkblue) > we use these colours to create assets like CTA buttons > people can run tests to suggest that $red works better as a CTA colour than $navy.

I noticed that some template images have been placed in /public/assets/images and fonts in /public/assets/fonts. These are to be bundled with the templates so actually need to belong with the related components so sprockets will compile them correctly.

When referencing the assets in .scss, they can use the asset-path helper instead of the server relative path which will break.

Hi guys

Just FYI.

The current styles on web.unimelb (in Safari 7.0.6 (9537.78.2)) are displaying the #uom-login Portal pop-up box oddly...

And in Chrome (38.0.2125.104), the "Please choose" content is off-centre.

Another thing to consider as we build out the templates is the issue of namespacing.

Name-spacing is a bit tricky because it's one of those issues that divides the basic and more advanced users.

The more advanced users, or those users using a CMS (like Matrix), have asked in the past for all components (e.g. Tables etc), to be name-spaced so that the default

For more basic users, this adds complications because they don't know enough to be able to add a class to their tables.

Unsure what the solution is here. Is there a way to have the best of both world's somehow?

Ideally the children here could be made simple uls.

I'd suggest that maybe a class could extend the base ul css which could then be applied?

Something we might need...

COMPLETE button lacks sufficient contrast (#FFFFFF:#3FC76E = 2.19:1)
Increase contrast ratio to 4.5:1

Copying across pursuit code has highlighted the need for an additional style or component for @herrweis and @waitingallday to develop (or maybe a different use of an existing style).

In the articles for pursuit there is massive attribution to paid authors. In this case, I believe that the authorship is sometimes given more prominence than the person being profiled. The authorship has also taken place on behalf of the uni, so reference to their moral rights over the piece is a necessity, but not something that needs to be made a big deal out of. This is different to the situation where an author is important to the university -e.g an academic writes something and the authorship adds weight to the article.

I think we need two authorship styles _ minor and major.

Any thoughts about how we incorporate this into pursuit? This feels like an authorship component with associated examples? Let me know if you want me to set something up.

Coming across an issue that I think we need to discuss.

Can we create a list of components that will be injected (and centrally controlled) vs. elements that will be added via local sites.

At the moment, looking at the templates site, I think the following will likely be injected:

• Footer
• Header
• Sitemap

Is that it? All the styles are obviously centrally held, but the example files in these components will need to be the production code that is made available. Perhaps we need a production.slim file for those components that will be rolled into some sort of injection?

My questions:

1. How do we do this code-wise? At the moment, for example, the footer code is in the layout.slim file. Ideally, it could be in the templates components folder (otherwise, why have it?)
2. How do we progressively enhance the pages (e.g. so that we have a default link to "Sitemap" stored locally, that is overridden when JS fires and injects in the global page and slider functionality). The same sort of thing would need to happen in the page footer and, likely, the logo lockup. We need the ability to swap that out globally.

Thoughts?

Slim, md, HTML, etc

Looking at the page templates, and thinking about the need to add documentation, sample markup and examples, I think it makes sense to have a seperate directory for each page template.

@neilang do you think that you could set one directory up this way and then I'll copy?

this feels like something that'd be a common use, so worth fixing.

This is two different jobs, but doing a similar thing. Mobile tab nav (select) needs to be auto-built with js rather than included in markup.

Mobile breadcrumbs should also do this.

As we build out this site, we're going to need to find a home to deal with the sorts of content tacked here.

http://the-thing.herokuapp.com/pages/codex/

Any thoughts about where this should live on this site?

I'm thinking that it'd be really useful for the following types of content to exist on this site:

• Pages (pages can have "tags" attributed to them which relate to audiences or topics).
• Posts (existing in some sort of blog - these posts are then linked to pages with relevant tags so that the right content can be displayed)

Pages

Deal with static content - eg. Policies, philosophies etc.

Posts

Deal with opinionated / useful content - eg. on the page which talks about the steps required to build a website, underneath each step there would be a collection of pages and posts relating to the permanent and opinionated ways to do these things.

Documentation

Our collaboration documentation should cover how to contribute to template documentation, pages and posts. At the moment I'm getting requests from Tom and also Carolyn to help build out this site and I'm thinking that it'd be great to get them editing directly into the repo.

Any thoughts about the best way to do this?

Ok, so this is a biggie and core to the templates. I'm putting this in text, as we're eventually going to need documentation, so having this reasoning here is useful for writing documentation.

We need to decide how the navigation in unimelb web templates works so I'm putting this here as an issue for discussion.

The things we need to work out are:

1. How many levels of navigation are supported in the local nav
2. How do "folders" behave? Eg. If a nav item has sub-items, what happens if you tap the parent item.
3. How do we integrate local nav with global nav

How many levels of navigation are supported in the local nav

From my experience so far, people require more than one level of navigation. Eg. Government uses two levels at present, and could easily go to a third level in some cases, especially in situations where we have very broad first level items (eg. Research, Study, Engage - this is something we've been encouraging).

Eg. Research > Research Domains > Research domain [name]

I'd suggest that if we can make the mechanism for drilling down a nav smooth, we should potentially support as many levels of navigation as a user might like, but then explain why using too many level of navigation might not be a good thing. This could also be enforced using visual indications of depth. Eg. indenting each subsequent level of nav.

How do "folders" behave? Eg. If a nav item has sub-items, what happens if you tap the parent item.

I'd suggest that we need to cater to three different situations

Scenario 1

• Nav item <- Page is signficiant, no sub-nav items

Scenario 2

• Nav item <- Page is significant (e.g. Study), several sub-items
  ** Sub-nav item
  ** Sub-nav item

Scenario 3

• Nav item <- Page is not significant (e.g. there is no page supporting this item), several sub-pages
  ** Sub-nav item
  ** Sub-nav item

This sort of situation can occur at any level of nesting.

In scenario 1, this is simple. Clicking an item takes you to that page

In scenario 2, we need to determine how you can both open a folder to see it's sub items and also click elsewhere on the nav item to open the linked page itself. (eg. it needs to behave as both a folder and a file - potentially a two part button - Andi has suggested that the FB menu on mobile (android) provides an example of this.

In scenario 3, I think the behaviour is pretty simple. Clicking a nav item without a linked page, but with sub-items simply needs to open the folder and expose child elements.

Any thoughts?

Just noticed (I think, with the change from v3 to v4) that you've included http: as the protocol, which will cause problems with sites over SSL.
Removing the protocol seems to work fine for me. Is there any reason it is required?
If not, it should be removed.

Imagery

There are a variety of image related issues we run into

Common issues with regards to imagery

• Images used that add no value to the message the page is trying to communicate
• Images added with text in them (which is not accessible or SEO friendly)
• Images added with text on top of them (and mobile display is not considered)
• Images added with text on top of them (and contrast is not sufficient to allow reading of text)
• Images are not compressed (and are very large)
• Images are too compressed (and are very pixelated).

I think there are solutions to all of these issues.

Images used that add no value to the message the page is trying to communicate

Need to develop some sort of guidelines for imagery use.

Images added with text in them (which is not accessible or SEO friendly)

We need to provide an easy way to do this via code

Images added with text on top of them (and mobile display is not considered) & Images added with text on top of them (and contrast is not sufficient to allow reading of text)

• Ensure that documentation for these components show both mobile and desktop implementations
• Potentially templates need to provide quite a few options for positioning of text on images (eg. potentially top-left, top-right, top-center, bottom-right, bottom-left, bottom-center, center, center-left, center-right) in conjunction with media queries?
• Ensure documentation makes it clear that only some images are appropriate for use in banners. For example, we need to find a way to discuss balance - eg. if you choose a busy picture (eg. students on the grass) you will need to minimise or forgo the use of text on this image.

Another approach to this is the approach taken by Medium, which seems to be able to make a huge range of images work on their homepage.

They also have an interesting convention for body images - they show the image without text to a point, but then fade it when text comes into view.

• Provide easy testing via ODL and Browserstack

Images are not compressed (and are very large), Images are too compressed (and are very pixelated), Images not suitable for retina

• Explain the use of tools like ImageOptim
• Create docs explaining image compression
• Create guidelines for the creation of retina ready images.

Just putting these here so we don't forget about them:

Advanced features that it would be great for us to include:

1. Flux (daytime, night-time reading mode)
2. Adaptive content (page content re-ordered based of what we know about you and blog level tags denoting audience suitability)
3. Quicklinks? @neilang - can you explain what you and Val have been working on here?
4. Responsive iconography.

Anything else that'd be cool?

Also consider a .minor or .subtle class for items that are not yet available / coming soon.

screenshot is about 760 pixels wide

So...with the sitemap and search, do we need to provide the option to scope the search. eg. Search this site vs Search the university?

Given we don't currently provide a search page template for a locally scoped search (do we need to do this as well?), and that I think it is potentially confusing for all searches to be uni-wide when you might be in the frame-of-mind of a local site another solution might be to simply do two searches at the same time and present the user with two panes of results?

Ignoring the terrible colours I've used, this is what I was thinking.

Step 1.

Step 2

Step 3

I also think we should make this sort of search available with a keypress from any page.