Wednesday, 27 October 2010

To Navbar or Not to Navbar

Recently, were asked to help a special school redesign their Uniservity platform to make it more accessible to their students. The main beef with the existing platform was that there was too much extraneous gumpf around the sides of the screen, and navigating to the relevant class page was too complex for many students. The ideal would be to do away with the Navbar entirely and as soon as a student logs in, they are taken directly to their class page. Now that is no mean feat in a platform where you cannot use PHP, and in the end we only partially achieved this.
The system we ended up with was as follows:

  • Student clicks a logo to log in and enters their login details.
  • Student is presented with a picture of their teacher which they click.
  • Student is taken to their class page.

When staff log in, they are presented with the pictures of all the teachers whose class areas they have access to plus any communal areas such as the Staffroom area.

By default, Uniservity will customise the standard Navbar depending on who is logged in and will only show them links to areas and resources they have the permissions to access. If you want to have more control over how the Navbar looks, and aren't happy with simply using Custom Images for the groups and having gaps between them (yuk!), you are stuck with a static Navbar which is not customised to the user's access permissions. This is fine for resources as, if these are linked to manually from class pages, a user will only see them when and if they get to the class page. So what is needed is a way either to customise the Navbar independently of Uniservity's standard functionality, or to do away with the Navbar completely and use graphics on the page which are customised to the user's permissions.

It turns out that both of these are possible using a little JavaScript and a thing called an iframe. The system that was devised works on the principle that if an image is stored in the Resources area of a group that a user does not have the permissions to access, that image will not load if it is on a page that the user is looking at. So, for instance, if Jonny is in class 3 and he looks at the homepage for his platform, which contains an image stored in the class 4 resources area, all he will see is a red cross because he does not have the rights to access the image.

So what we could do is store an image which represents each class (say a pencil with the class's name on it, or in the case above, a photo of the class teacher) in the relevant class's Resources area and set the Access Permissions so that it is only visible to that class, either using All Group Members or Profile Sets, depending on which way round you have it set up. The problem with this is that if we then place these images using their URLs into the homepage or a Custom Navbar, we will see the class images that are accessible to us but we will also see an unsightly red cross for those that aren't. So how do we get rid of the red cross? Enter JavaScript.

Now Uniservity copes well with some JavaScript when entering it into the Source Editor for group pages, but the editor can sometimes do odd things and strip out code that it doesn't recognise. For this reason, I decided to approach it from a slightly different angle. I created the homepage using a text editor and saved it as an HTML file, then uploaded this as a Public resource to the Resources area of the platform's top level group. I then put this code into the homepage Source Editor:

You will notice the iframe tag here, which creates a window (in this case an invisible one) into another webpage. The style properties set the frame which appears around the edge by default to zero pixels so that it is invisible (as well as the frameborder="0" attribute). Also being set is the width of the iframe, which is made to be 100% of the width of the window (in this case the central area of the Uniservity page), and the scrollbars which are turned off so that the iframe is completely invisible and it appears as though the content coming from the source page is simply on the page with no frame. The source page is referred to by the src attribute, and this URL is the URL of the manually created and uploaded webpage I made reference to above.

This method circumvents the filters which decide what one can and cannot put into the Source Editor for a group homepage, so we are free to use whatever JavaScript we like without worry. The JavaScript in question which prevents an image displaying if it is not accessible to the user is shown below:

The magic part of this is the part which starts onerror=. This is what is called an event handler and it is basically saying that if an error is thrown up when trying to load the image concerned (such as it isn't accessible), do something. The something it does is to change the style properties of the image to make it invisible and have zero width and height. That means that if the image does not load, it will not display at all. You can see how this could be used in a Custom Navbar to acheive what the inbuilt Uniservity system does but with much more flexibility in what the Navbar actually looks like.

Please note that I have never tried this code directly in a Custom Navbar, so I don't know whether it will work without being stripped out. In my experience, the Custom Navbar box is a lot more forgiving in terms of what it will allow, so the chances are it would work. If not, you could always use an iframe as in the example above and create the code for the Custom Navbar outside Uniservity then upload it as a resource.

No comments:

Post a Comment