Web Services
  • Social Media

  • December 2014
    M T W T F S S
    « Nov    
  • A A A

    Archive for the 'usability' Category


    By Sonja M Van Praag, on 11 December 2014

    For those who attended WebNet on December 3rd, 2014, those who wanted to attend but couldn’t and also those who never thought of attending:

    1. LectureCast of WebNet December 3rd, 2014 – with speaker Dan Jackson (WAMS) and Paul Boag (Headscape) – 55 minutes.
    2. Paul Boag’s Digital Transformation for HE (pdf to download)
    3. User-testing website – to get users video-ed whilst testing
    4. Free user-testing website ‘Peek’ with generic tasks
    5. Crazy Egg website – to see where people click on your site
    6. Don’t make me think by Steve Krug - if you have time to read a short book…
    7. Hemingway App – to help you edit long paragraphs

    Paul Boag at WebNet 2014 at UCL

    WebNet: Paul Boag – Wednesday, Dec 3rd at 2pm

    By Sonja M Van Praag, on 17 November 2014

    Web & Mobile Services are inviting you to this term’s WebNet on December 3rd , 2014.
    It will take place at 2pm – 4pm in Lecture Theatre B17 in the basement of 1 – 19 Torrington Place.

    We are  very excited to confirm Paul Boag, digital strategist as our main speaker.

    Paul Boag is one of the founders of Headscape, a prolific blogger widely known for his very practical and sometimes controversial blog posts, who tweets regularly at https://twitter.com/boagworld and has over 20 years’ experience of helping organisations manage digital change.

    We have asked Paul to touch on a number of issues relevant to web Editors in his talk about ‘Digital Strategy’ such as content strategy and user testing, but are waiting to get the title of his talk confirmed.

    Dan Jackson from WAMS will be updating you on Indigo, the design language created by Web & Mobile Services.

    We will be advertising the event shortly – no need to book.

    Please look out for news, both in ‘The Week at UCL’ and on the ISD website.

    Looking forward to seeing you on December 3rd.

    Web & Mobile Services

    CMS Planning and Prioritising

    By Dan Jackson, on 5 July 2013

    Being somewhat shamefaced that we haven’t blogged for 15 months, it’s tempting to start with a list of excuses for the pregnant pause (big organisational changes, workload – the usual suspects.) However, instead of being introspective & retrospective, this post is about looking forward to where we want to be – and we’re certainly doing a lot to get there; constructing a digital strategy and the governance framework that needs to go with it; thinking about how to position our Web and Mobile Services team as a ‘Digital Agency for UCL'; working with Mark Boulton Design on a common Design Language that will enable us to develop visually consistent, responsive websites for the University; undertaking a rigorous process of service improvement.

    Our CMS review process

    Another critical activity that’s well underway is a review of our Content Management System (CMS). We know that the performance and scalability of our existing CMS is a concern, and that we’ve got work to do in order to get it up-to-date and make the underlying server and application stack more performant and resilient. From a recent survey of our CMS users, we also know that the content editing process is often a frustrating one; performance issues and  poor usability are frequent causes for complaint.

    More strategically, however, we’ve also been thinking about what functional and non-functional capabilities we want from a CMS, and how to enable ourselves to be future friendly; after all, it’s impossible to establish whether our current CMS is fit for purpose until we we know what we want it to do – both now, and in the future.

    CMS planning workshop

    To assist us in this process of CMS analysis, and to help validate our decisions, we’re working with the digital consultants and CMS experts from J.Boye. Over the summer we’ll be eliciting the opinions of a representative pool of UCL’s content editors, but we kicked off our investigations this week with a workshop for senior stakeholders from Information Services and Communications & Marketing to review CMS best practices and trends, and to define and prioritise our digital / CMS activities with some MoSCow analysis.

    Our priorities

    CMS worksop: prioritising

    So what did we conclude?At the top of our prioritised  list of “must haves” was a mix of activities that must happen in order to support our process of change and improvement, and a set of features that our CMS must offer as core capabilities:

    1. Digital Strategy & Governance (inc. senior management understanding of importance, central web funding)
    2. UX (optimal UX for all user groups, intuitive CMS editing interface)
    3. Mobile (responsive design, mobile first)
    4. Performance (inc. need to define performance budget & establish fit-for-purpose server architecture)
    5. Content & Metadata (structured for re-use, social/CMS integration)
    6. Compliance with corporate branding
    7. Security
    8. Actionable measurability
    9. CMS flexibility & extensibility
    10. System / data integration & interoperability

    CMS worksop: prioritisingMeanwhile, our “should haves” and “could haves” listed those items that we felt we should strive for, but that either may not be possible in the short term, or were not perceived to be core capabilities for a CMS:

    1. One UCL website with a global IA
    2. Standardisation of design & development processes / assets
    3. Focus on search
    4. Maturity of CMS vendor
    5. Controlled flexibility (controlled by Web & Mobile Services, flexible for editors)
    6. Capable of being UCL’s single CMS
    7. Skilled, professional content editors (federated model)
    8. Integrated, central DAM (digital asset management) system
    9. Simple, usable, integrated authentication
    10. CMS technology appropriate to UCL
    11. Scalable solution
    12. URL namespace defined
    13. Content review capability

    It was a good, well facilitated session (thanks Brian), and was really encouraging to see Directors & Heads working together to ponder on our CMS requirements and to deliberate on, and help prioritise, those tasks and issues at the heart of our web service improvement plans. We’ll be using this information to inform our Digital Strategy and CMS decision-making processes – watch this space.

    What's a good URL?

    By Nick Dawe, on 4 August 2010

    It may seem like an unimportant issue, but web editors might be interested in reading a recent post from CSS-Tricks detailing good practice for writing URLs:

    I was particularly struck by the URI ‘speech-friendly’ test: Can you easily say a URL down the phone to someone else, or do you have to pause between characters to say whether they’re lower/upper case? Do you have to describe any funny punctuation marks that appear? Is the URI unhelpfully long, and indeed does it even make any sense?

    The Pros and Cons of Website Tickers

    By Nick Dawe, on 8 October 2009

    There have recently been a spate of new websites at UCL using ‘news tickers’ – banners of short headlines that  emerge across a space on a web page. These vary from each headline character appearing at short time intervals, to entire headlines slowly scrolling into view.

    It seems that they’ve now been made particularly popular by the BBC News website’s use of such a ticker at the top of the page, showing ‘latest’ news stories. The new UCL homepage also uses a similar ticker which displays the most recent news articles on the site.

    UCL news ticker

    So why write a blog article on the ‘pros and cons’ of tickers? Surely tickers are consistently useful ways of disseminating new information to regular visitors of a site?

    Tickers indeed are very useful for this, and for sites such as the BBC and UCL homepages which are guaranteed to have thousands of visitors who often revisit the site, they may well help those users quickly see what new features and happenings have taken place since their last visit. But what about the downsides?

    1. Distracting users from key content

    Have you ever been reading web page content when suddenly, something changes in the corner of your eye, and you look to see what’s happened? After realising that it’s just the ticker/animated .gif/annoying Flash advert, you go back to reading the content. Except you can’t find where you left off, and have to spend a few moments just trying to get back to the last sentence you read, and oh look, what just moved up at the top of the page?

    Any content that moves on a page is going to cause some kind of distraction for visitors who are trying to read any length of content on a page. If a webpage is full of short chunks (such as the BBC and UCL home pages) this isn’t going to be such a big issue. But as soon as you introduce a few paragraphs, and actually expect your visitors to read them, tickers may not be such a good idea.

    Another solution to this, again implemented in the UCL home page, is to allow users to actually pause the ticker if indeed it is causing too great a distraction for them.

    2. Difficulties for users’ reading habits

    In user tests for the 1997 sun.com website redesign, usability expert Jakob Nielsen got typical target users to look at different aspects of the website. One aspect was that of a scrolling ticker, which received negative feedback. Some users mentioned that ‘they were hard to read and time-consuming to interpret'; and that they ‘kept missing the the beginning of the text and thus had difficulty understanding what the message was about’.

    If you’re trying to communicate vital information to users, is a ticker going to be the most suitable method, bearing in mind some users (including many dyslexics) will have real trouble reading from moving text? Some tickers, like the UCL homepage’s, will not suffer from this issue so badly, because the text itself isn’t moving. Others, in which full sentences pass from one side to the other, will certainly cause problems.

    3. CPU

    This is only something we’d noticed recently in our work on the UCL home page. There are quite a number of JavaScript tickers available that actually suck up an awful lot of CPU. One ticker we played with lately would actually bring our office PC’s CPU to 100% every time we opened the webpage in Firefox, which was quite irritating. Tickers already set up in the Silva CMS shouldn’t cause such problems, but if you do try to use other ticker scripts, it’s well worth checking this before implementing them!

    Overall, tickers can have great potential for alerting regular users to news and changes to a website. However, it’s worth spending some time considering whether they will actually be of use to your website’s key user targets, or whether it will cause them more irritation than genuine help.

    How we read on the web (we don't)

    By Nick Dawe, on 30 September 2008

    Common sense would insist that the way someone reads from a computer screen is going to be different from how they would read from paper. Indeed, many web pages throughout UCL are written in ways more easily digestible for the casual web surfer (shorter chunks of content with more concise information). Users can hopefully get to the exact information they need, and read it, in as short a time as possible.

    However a recent study by Jakob Nielsen suggests that the way users read content is far more ‘magpie’ like and perhaps even lazier, than many of us had ever guessed.

    Chronicle website screenshot

    Nielsen found that as readers ‘read’ hundreds of webpages, they read in a bizarre pattern, similar to the letter ‘F’. To quote the Chronicle of Higher Education article:

    At the top, users read all the way across, but as they proceed their descent quickens and horizontal sight contracts, with a lowdown around the middle of the page. Near the bottom, eyes move almost vertically, the lower-right corner of the page largely ignored.

    With this in mind, perhaps we need to take a completely new look at the way that we present all kinds of content on our webpages. Can we really assume that casual users visiting a page will read the majority of its contents, or is it more likely that they’ll read the beginning and then look out for particular keywords?

    Read the full article at: