Author Buzz

Where Authors & Readers find each other

The Fantastic (Group) of Lord Matt, Super Geek

by Matthew Brown

WishList: A proposed extension of OpenGraph

March 23, 2025 in coding-and-development by Matthew Brown

I’d like to propose an extension of the OpenGraph protocol for easy wishlist creation. A select few might be aware that I maintain a wishlist. Currently, I manually enter each gift idea into a database. It would be dead helpful, if I could just provide a link to a page that represents an item that can be given.

This post contains some marked-up HTML and I don’t know how it will look on federated sites. You may need to open the original page for best results.

Existing art that might work

OpenGraph pretty much has what I need already.

<meta property="og:type" content="product.book" />

As far as I can tell, the list of types in the product space is as follows – album, book, drink, food, game, movie, product, song, and tv_show. Some of this maps well to gift listing.

  • album is generally a thing you can buy and, thus, gift (digital purchases and releases are a bit fuzzy)
  • book is a thing you can buy (includes ebooks or all kinds)
  • drink is probably a thing you can buy or, sometimes, make
  • food can be a thing you buy as a gift but is not strictly limited to that
  • game is largely a thing that one can gift but exceptions apply
  • movie is a thing you can watch but might map to DVD or Blueray which can be gifted
  • product (product.product) is generic and is probably giftable
  • song is something you listen to but might map to CD or digital for a given single
  • tv_show is something you watch but could map to Box Set (DVD/Blueray/etc.)

However, there are some giftable things that do not fit well within the defined product types.

  • A custom voucher for a favour like babysitting, housework, a shoulder massage, and other no-spend gifts.
  • Something that you could make such as a cake, cookies, pie, a custom set of shelves, a GWL card, and so much more.
  • The clarity that the product in question is something that can conceptually be given. Perhaps in a given format or media.

I considered adding one more product value

To the product types, I would like to add something that indicates the thing that can be given. The simplest version of that is probably “gift” or “giftidea”. It would set the page as a thing that a person can gift to another. Which would make it ideal for wishlists. Something like this:

<meta property="og:type" content="product.gift" />

This is not entirely a good fit. “Product” as a gift is conceptually a little narrow and is a bit too abstract for my tastes. Plus, it could break existing validators that are unaware of the new gift product type.

The other option would be a new base type with its own subtypes. This is problematic as it would create the possibility for duplicate potential types for a given page. Fortunately, there is a better way.

A namespace for OpenGraph gift ideas and wishlists

That better way uses good old namespaces.

If the type is not the right place to insert metadata for giftables, perhaps a new schema might be called for to cover instances when the current OpenGraph types are not a good fit. This gives us, I think, three new objects – gift idea, the wishlist, and an entry in a wishlist. Maybe it would look something like this:

<head prefix="wishlist: https://example.com/ns#">
<meta property="og:type" content="wishlist:gift" />

This type would provide a catchall for wishlist gift ideas that don’t fit well into the wider graph. It would also avoid breaking validators. The same namespace could be used for all wishlist, gift, and wish object data.

wishlist:gift object data

The namespace could provide other wishlist item data points – estimated price(s), and known retailers, for example.

<head prefix="wishlist: https://example.com/ns#">
<meta property="og:wishlist:gift:price" content="£32.99" />
<meta property="og:wishlist:gift:price" content="$99.99" />
<meta property="og:wishlist:gift:retailer" content="amazon.co.uk" />
<meta property="og:wishlist:gift:retailer" content="CEX" />
<meta property="og:wishlist:gift:retailer" content="Harry's Local Trade Shop" />

There is a lot more data that could be added here but I’m not sure it is strictly necessary. Maybe there is something that should be here but I’ve not thought of. I think that the rest of the data – product information, could be covered by the existing OpenGraph namespace. If there are any obvious gaps, please comment, reply, or mention with your thoughts.

wishlist:list object data

If we’re going to have a custom namespace, why not also include the wishlist itself? This can be where each wish in the list could go (technical limits may apply).

<head prefix="wishlist: https://example.com/ns#">
<meta property="og:type" content="wishlist:list" />
<meta property="og:wishlist:list" content="https://example.com/lists/matt/birthday/" />
<meta property="og:wishlist:list:user" content="Matt" />
<meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/tfdobl" />
<meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/apple" />
<meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/cake" />
<meta property="og:wishlist:list:wish:more" content="https://example.com/lists/matt/birthday/page-2" />
<meta property="og:wishlist:list:wish:more" content="https://example.com/lists/matt/birthday/page-3" />

For wishlist:list:user, I toyed with calling this “wisher” and a few other things but finally concluded that there was no good reason to invent new terms when the existing idea of a site user or member was already well established.

There are other data points that might fit inside the graph for a wishlist. Please suggest any you think I should add here.

wishlist:wish object data

Wishlist entry implies the existence of wish with details such as – the gift wished for, how badly you want it (priority), how many you want, why you want it, and the list the wish is from. The whole thing might look like this:

<head prefix="wishlist: https://example.com/ns#">
<meta property="og:type" content="wishlist:wish" />
<meta property="og:wishlist:wish:gift" content="https://example.com/shop/item/tfdobl" />
<meta property="og:wishlist:wish:priority" content="low|medium|high" />
<meta property="og:wishlist:wish:quanitity" content="1" />
<meta property="og:wishlist:wish:why" content="This book is the only one missing from my collection." />
<meta property="og:wishlist:wish:inlist" content="https://example.com/lists/matt/wishlist-birthday" />

There are maybe other optional elements. Please do suggest data points you think should go here. Is, for example, wishlist:wish:why the best way to label that information within the graph?

Existing OpenGraph object data

OpenGraph neatly provides most of the other data points that could matter, I think.

<meta property="og:title" content="Fictional Dictionary of Bad Language" />
<meta property="og:url" content="https://example.com/giftideas/tfdobl" />
<meta property="og:image" content="https://example.com/images/tfdobl.jpg" />
<meta property="og:description" content="..." />
<meta property="og:determiner" content="the" />
<!-- ect. -->

One small privacy issue

While writing this, it occurred to me that I did not really want to put my postal address and other sensitive information online as part of a social graph. To avoid that I went ahead and assumed that the wishlist site handling the list for the user would implement some way for gift-givers to privately obtain such data if it was even needed at all. Perhaps with some sort of request/grant system or some other similar privacy controls.

Thoughts and feedback?

That’s my ideas about presenting wishlists, gifts, and wishlist items using OpenGraph. I’m open to critique, objections, praise, or any other feedback.

Tags: / ideas / OpenGraph / wishlist No Comments »

by Matthew Brown

I found another (markdown) bug with the Universal Credit website

March 16, 2025 in uncategorised by Matthew Brown

Today, I learned that gov.uk websites use Mark Down – a system for marking up text that can safely be turned into HTML. So too does the Universal Credit Journal system (sort of).

It looks like the journal system is trying to use Mark Down, and the specific code for that is fighting it hard.

I have discovered that it tries to throw rounded brackets (like this) around links. By default, “GOV.UK Notify will convert the URL into a link for you.” This is what is happening with the URLs added into the Universal Credit Journal, but the output method refuses to process the Mark Down. The UK government even has its own beucracy laided URL shortening system to make Mark Down links easy to read.

‘I have no way of knowing if it was decided that the general public was not to be trusted with the very safe Mark Dow system; or if it was determined that Universal Credit claments were too stupid to use it; or if the hack job that is the Journal system is just that badly written.

No Comments »

by Matthew Brown

The unclear UK Online Safety Act cannot possibly hope to process all the bloggers

March 13, 2025 in uncategorised by Matthew Brown

The UK Online Safety Act 2023 makes it the responsibility of site owners to carry out a laundry list of protection behaviours. The UK Government has failed to say if this act applies to blogs. It has been clear that it applies to all websites with UK users. As usual, the UK government leapt in without understanding what it was doing (again).

At a rough estimate, there are over 450 million WordPress blogs plus other CMS based content, forums, and so forth. To get through those in one year, they would have to deal with 1,232,876 blogs a day for a year with no days off for good behaviour.

Forcing that many indie bloggers to fill out paperwork to confirm that they delete harmful contact and spam (like we all do) would be like trying to empty the ocean with a teaspoon.

The fact that the government has failed to clarify if the Online Safety Act covers personal and single-person websites (like all of mine) means one of a few things:

  • Someone wants to go after specific bloggers
  • They have no idea what they are doing
  • They have no intention of going after bloggers and indie websites but cannot say that
  • Nobody has thought this through
  • The law’s authors think it will magically make the Internet safer with no effort

I fear it might be a little bit of each of those. But that also means that the law is toothless to go after bloggers. After all, no Prime Minister wants a headline to read, “Government fines mother of three £18m because someone left a mean comment on her son’s blog”.

While it is not nice to be uncertain, I think that the practicalities mean that your average personal blog will be completely fine. Forums, on the other hand, could be a little more tricky. I hope that the same small things and large numbers issue keeps well meaning over reach off of our friendly corners of the Internet.

For Author Buzz UK, I shall probably have to write a risk assessment I wonder if the following will do?

We let members post stuff on the condition that they are nice and also on topic. Spam and harmful content will be sent to the spam delete bin along with the poster’s account.

Every blog and forum moderation plan ever

Ofcom has offered some guidance for what it is worth. They don’t say where your risk assessment is supposed to be sent.

Fingers crossed, I guess.

3 Comments »

by Matthew Brown

A new blog for my visual novel

March 8, 2025 in uncategorised by Matthew Brown

I’ve been posting here from time to time about my visual novel plans. Before I get to the giant epic that is the story of a tea-drinking wizard, I have set myself a more reasonable goal – a simple story about a person lost in a magic maze.

This story is currently under the working title of The Endless Rooms (although variants on The Lost Rooms are also in my head).

To make life easier (and to avoid spamming small posts from this blog), I have set up the project with its own Mastodon/Fedi/WordPress thing on isBrill.com. This can be found at https://endless-rooms.isbrill.com/ and subscribed to on Mastodon and related fedi-sites.

Tags: / blog / news / projects / visual novel No Comments »

by Matthew Brown

Why is the Universal Credit website so bad?

February 25, 2025 in coding-and-development by Matthew Brown

I am professionally embarrassed for whoever created the Universal Credit Website (UCW). In this post, I will explore why the website is so bad and what should be done to fix it.

I’m writing this in the hope that someone within the government with the power to do something reads this and implements at least some of the changes that the site is so desperately in need of. (The same reason I analysed the Boots website). There is a summary of changes needed at the end of the article.

Legal disclaimer: I’ve used screenshots of the website. This is legal because (1) fair use and (2) OGL.

A brief intro to Universal Credit

Universal Credit is the UK’s highly criticised unified benefits system for those out of work or currently unable to work. In theory, it was also an income support for those just starting out in self-employment. It was the brainchild of the political right (the Tories). It has an unbelievable number of shortcomings. Many hope that Labour will refine or replace it but I’m not holding my breath on that one.

Claimants of Universal Credit (UC) must make all contact through the Universal Credit Website. Are you old and have never used a computer? Too bad.

You’d think that such a key instrument of the Department of Work and Pensions (DWP) would be fit for purpose and well designed. You’d be wrong to think that.

The DWP are still migrating everyone who claims any sort of assistance to UC. This, I think, is a terrible idea. Not only because UC is a mess but also because the website barely works.

Dangers of the Universal Credit Website journal’s lack of app

The DWP has not (as far as I know) made an app for UC users. So guess what the scammers made. Go on, guess, I can wait.

Yep:

People are being warned about a scam involving a fake Universal Credit app and text messages.

The app is called ‘Universal Credit UK’.

The Department for Work and Pensions is investigating, and is encouraging people not to use the app or respond to any suspicious text messages.

People should use only the DWP Universal Credit website, and if you are unsure how to claim, the Citizens Advice Help To Claim service can offer support on 0800 144 8 444.

Anyone who has given information to the scam should report it to Action Fraud on 0300 123 2040.

Warning over fake Universal Credit app and text messages, CAB Hull and East Riding

I’m going to come back to this topic towards the end where I get technical about how to fix the UCW.

Shortcomings of the Universal Credit Website’s User Interface

There is so much wrong with the UI of the UCW that it is hard to know where to start. It is clear that the site has been created for the benefit of the UC’s management and agents without any consideration for the people it is supposed to serve. This is a common failure by businesses that are all set to fail – they create things for their needs and not the customers’ needs. You’ll see some clear examples of this soon enough.

It was reported that about one-third (32%) of benefit claimants being migrated to Universal Credit failed to make a valid claim.

Statistics released this week by the DWP show that 32% of all claimants sent a universal credit (UC) migration notice up to the end of February 2024 failed to make a successful claim and had their legacy benefits terminated.

In total, a shocking 284,660 individuals did not make a valid claim and had their benefits stopped.

One third of UC migration claimants fail to make a successful claim, 15 August 2024, benefitsandwork.co.uk

I strongly believe that a large part of the problem is the shockingly bad Universal Credit Website (along with the fact that UC is badly implemented as a whole).

The Universal Credit Website is a terrible CRM

This website that all Universal Credit claimants must use to communicate with the DWP is essentially a CRM (Customer Relationship Manager). CRM software is at the heart of most successful businesses. The UC one is possibly the worst CRM I have ever witnessed.

You could have slapped up an instance of WordPress running a free CRM plugin and gotten something better.

I’m going to show you many of the ways in which the UCW Journal fails at being a simple CRM thing. In short, the design, implementation, and customer interface is a giant steaming turd. I can find, at a push, one nice thing to say about it.

Misleading landing pages

If your session times out and you sign back in, this is what you see.

Screenshot of a pointless Universal Credit website page

It looks for all the world like you have to recreate your account. It is only when you more closely examine the page that you find the link to sign in to the UCW. Like, wait a minute Scoobie, didn’t we just sign in to that?

This is either an example of incompetent design or deliberate arse-hole design. Either way, it can only serve to confuse people leading, I have no doubt, to cancelled accounts or sanctions. There is no excuse for this complete failure.

Unclear priority elements

This is what you might see once logged in for real. (I’ve redacted any specific or personal information).

Screenshot of the Universal Credit website main page with a few redactions for privacy reasons.

Can you tell just by looking at this what the most important section of the site is? The part you must pay special attention to in order to keep your claim live?

If you said, “Journal” then you are already ahead of the curve. That link top right in a grey box is the thing that matters most. Never mind that grey is UI shorthand for unimportant or disabled.

Not to worry, there are eight boxes lower down. One of which also takes you there. Maybe it is just me but my automatic ad-blindness had me ignoring all of that advert-looking crap until I started writing this article. The UCW “Journal” is a sort of half-arsed CRM (customer relationship manager). As a CRM the Universal Credit Journal fails so hard that I’ve given it its own subheading. A lot of this post will talk about how hard the journal system fails.

The Universal Credit Journal language is all wrong

There is a way to use language such that a task that is needed and a task that has been completed are easy to tell apart. Universal Credit’s designers clearly wanted to have nothing to do with these good design principles.

Someone needs to go back to school and learn that English has tenses (past, present, and future)

Take a look at this and tell me if the two blue links are tasks pending or tasks completed.

The Universal Credit website's journal system is bad

If you said tasks completed, you would be right. If you said tasks pending I completely understand. That’s because in English “Report a change” is an order or a thing to do while “Reported a change” is something that happened in the past.

In technical terms, the tenses of the entries are incorrect. I’m a native English speaker and long-time technical user who expected bad UI and even I was unsure. Now, you could blame this on my dyslexia and you may be right to do so. However, if I (a talented geek and native speaker) struggled with the incorrect tenses used here how much more would non-geeks and English learners struggle?

How hard would it be to change “Tell” to “You told” and “Report” to “You reported”? Or, if feeling lazy Prepend “Completed:” to the linked entries? It is only now that I noticed the first one ends with “completed” (the second one does not). If I didn’t see it, who else didn’t?

Send is not the right word here

When I ask for comments on my blog I do not say “send me your comments”, I say “leave me your comments”. That’s because “send” implies transmission not interaction. So, why-oh-why does the reply link say “send reply”? I’m not emailing you, I’m leaving a comment.

Needless priority given to dates

Let’s look at that Journal thing again and tell how important those dates and times are:

The Universal Credit website's journal system is bad

The date and author of the entry are what is known as metadata. That is, data about the data. The only key element here is the entry itself. Yet the entries get about half the space as the rest is eaten up by metadata which is treated as equally important.

It looks worse on mobile.

The Universal Credit website's journal system is worse on mobile

Vital calls to action are unlinked

Let me quickly introduce you to a business term – CTA or Call To Action. A CTA is the thing that you want the person to do in response to what they have read. My CTA is usually, please leave me comments because I love comments.

In this example, the CTA is to carry out a “to-do list” action. Failure to do so means loss of money.

The Universal Credit website's journal system's wording leaves much to be desired

The link, however, is for leaving a reply. Without scrolling back up to see the rest of the UI, can you tell me how to do a “to-do”?

Those of us used to dealing with shite websites could probably find our way to the top and find the other greyed-out link (grey means unimportant remember). Click that and then scroll through any pending items and find the one that means you get paid. I guess the design principle here is: If you want this money, you had better work for it.

On social media, when they want you to fill out your profile, they will show you a CTA with a link to the place where you do the thing. This is because they know that you link vital actions rather than forcing users to go searching for them.

Universal Credit leaves its users searching. No wonder it was reported last year that 900,000 Univeral Credit cases were closed by the DWP

The reading order is potentially confusing

Take a look at this journal entry and see how quickly you can work out if the user needs to go to an appointment or not.

UC Journal with wildly inappropriate reading order.

This is where the user is expected to regularly check for important updates.

I’m saying that this UC Journal has a wildly inappropriate reading order. The first thing you see as you scroll down is an appointment has been cancelled. Oh, you might think, did I have an appointment? There was, you learn, an appointment made the day before.

There is, as far as I have been able to learn, no way to connect one journal entry with another.

Universal Credit is not Twitter, FFS!

For no reason that I can ascertain, replies have an arbitrary limit.

The Universal Credit website's journal system "send reply" box

If I have several pages of information to share, should I end each section with “1 of 6”, “2/6”, “3/6”, etc.? All that would do is make the textual content hard to follow because the DWP UC “Journal” is not threaded nor is it object-grouped. It’s just a wall of text in reverse chronological order.

The Universal Credit website is buggy as hell

Then there is this shit.

The Universal Credit website's journal system's broken UI

When you click in to “send reply” the whole page flips out. Would you like to see that in a small hand-held viewport?

The Universal Credit website's journal system doubly broken UI on mobile

I hope you like scrolling.

This is not even a new problem. People were complaining about the UI back in 2017

Application online is not user freindly and is quite a messy website. Gov id verification are complicated and have system failures and required me to phone the Gov id verify contractor for technical support. Universal credit website need to be simplified and made user freindly. The goverment id verify contractors will boil yourr blood by asking you to fill in your personell details at least three times, its mad.

Written evidence from Miss Amina Khatun (UCR0073), committees.parliament.uk, October 2017

Yes, that quote is part of the official parliamentary record. Legally speaking, the DWP “knows” there is a problem. I mean, come on, surely they have gotten the message by now, right?

You cannot attach evidentiary documentation

Have a report from a doctor that may be relevant to your UC case worker? Shall I tell you how you can show it to them? Go on, guess.

Did you guess, attach it to a journal entry? Oh, you sweet summer child, no, the journal cannot take attachments. If you want them to see the document, you had better print it off and get a face-to-face in-person interview where they will not make any record of the document at all.

As I have already said, the DWP UCW is an incredibly poor CRM.

Not that I didn’t try (and found more bugs)

I tried to add medical information to the Universal Credit website. I, quite wrongly, guessed that “change of health info” was the right path. It was not. The account now has a pending “to-do” (complete the change of health thing even though there is no change to report).

Bug: It is impossible to cancel an incorrectly started task.

The Universal Website was created for the DWP’s requirements, not your needs

The purpose of the site is to make users jump through the hoops that the DWP (Department of Work and Pensions in case you forgot who those clowns are) demands. As I hope I have shown, they make no effort at all to assist you in this. If you cannot use their CRM, too bad, I guess.

I can think of only two reasons to implement the UCW like this:

  1. Gross incomitance
  2. Actual malice

With the DWP those two are hard to tell apart.

The Universal Credit Website is unfit to be the only point of contact; especially for older people

There is so much more I could complain about from an end-user perspective but I hope this brief overview of the UCW’s failings gets my point across.

I’m a technology guy. My profession is making things like this. I struggled to use the system. How the heck would my dad cope? He can barely use his (non-smart) mobile phone and needs help to read his text messages.

In May 2021, Helen Undy, Chief Executive of Money and Mental Health said, “People who need help with Universal Credit are being ”. Here’s the link if you don’t believe me.

In the last five years, it looks like very little has changed.

I therefore put it to you that the Universal Credit Website is unfit to be the only point of contact; especially for older people and those with limited computer literacy.

The Universal Credit Website HTML and (lack of) web standards

This is the part of the post where I start to get a bit technical as I answer the question I asked at the start – Why is the Universal Credit website so bad?

I’ve already covered the weak and broken UI design approach. In this section, we are going to talk about web standards.

The journal looks the way it does because, for some unknown reason, someone decided to use HTML tables for layout. It is a web standard that tables should be used only for tabular data.

This is semantic, not tabluar data

tables for layout are wrong

Whatever junior dev wrote this may have used tables because the data came from a database table and they did not know any better. However, this is not tabular data. Let me give you all the reasons why this is not tabular.

  • The journal entry is content and the rest is metadata for context.
  • You did not intend for us to sort by date or author
  • There is nothing to take a sum, average, or other calculation from
  • Some of these have subforms (send reply) that break tabulation
  • It would look nicer if the metadata were stacked on smaller screen sizes
  • The table imparts no additional data to screenreaders
  • CSS grid is faster, harder to break, and easier to make responsive

Tables for layout are dumb

This is what the experts say about using tables for layout:

It was common in the early days of the web to use tables as a layout device. Before the advent of modern standards-based browsers, this was the easiest way to make sure that page elements were arranged properly on the screen.

This design pattern is now considered very bad. It is bad for the user experience, bad for SEO, and bad for developers who have to maintain pages.

You should not use table-based layout under any circumstances.

HTML Tables: Find Out When To Use Them (And When To Avoid), Adam Wood, html.com

Here’s another that explains why HTML table layout is bad for end users:

1) Tables shouldn’t be used for page layouts because they are:

  • Slow to render as the browser needs to download most – if not all – of the table to render it properly
  • They require more HTML than non-table layouts which means slower loading and rendering, as well as an increased bandwidth usage
  • They can be a nightmare to maintain as they can quickly get complex
  • They can break text copying
  • They negatively affect screen readers and may make your content inaccessible to some users
  • They are not as flexible as using proper semantic markup
  • They were never intended to be used for page layouts
  • Making tables into a responsive layout is very difficult to control

2) Use a table for tabular data. That’s what tables are for.

John Conde, Webmaster’s Stack Exchange

Let’s break down a few of these:

Tables negatively affect screen readers and may make your content inaccessible to some users

A good chunk of the users of the Universal Credit website will have long-term disabilities. Those who rely on screen readers are likely to face a nasty mess as they try to use the website.

This is likely in breach of the UK’s Disability Discrimination Act 1995 and the Equality Act 2010. I am not a lawyer but activist groups might want to look into this.

Tables are not as flexible as using proper semantic markup

This is why the site looks god-awful on mobile. Using any one of the many flexible standards could make the journal resize in a useful and pleasing way on smaller screens. As I have said, the date and author are metadata and have no business taking the prominence they have been given. As the journal entry is the salient thing, the journal is NOT TABULAR DATA.

The nineteen-nineties called – they want their web design back.

Tables are a nightmare to maintain as they can quickly get complex

This is why the reply thing is broken. It has the wrong number of table divisions which breaks readability and looks bloody stupid on a government website.

Tables are slow and use excessive data

This is a website for people who have limited spending money. Why then, choose a markup that burns data faster than needed, loads slowly, and is frustrating to use with disability support software?

Tables are for data only – not journal entries with sub-forms

I put it to you and the DWP that using tables in the UCW at all was a failure in design, planning, and implementation. Replace the tables with nice semantic div tags, some CSS flex-box, auto margins, and responsive design. The metadata should stack under or over the entry on smaller screens.

This is beginner-level flexible and accessible design stuff. Not to mention the DWP is, in my opinion, failing to uphold the laws about accessibility made by the institution (the government) that they work as part of.

I’m not going to teach the DWP how to do this properly. They should know that if you pay peanuts you get monkeys.

The weird thing is the DWP do it right elsewhere

On the UCW home page (even though it defaults to to-do) the supplementary navigation items are responsive and stack appropriately on smaller screens.

If you can do it on the home page, why not on the Journal too?

The Universal Credit CRM is missing a few things

I’ve said quite clearly that the UCW is a terrible CRM example but it can be fixed. We just need to add a few features.

No tables, darling

I covered this enough, I think.

Edna Mode says, no tables

Threading or object grouping

The journal is currently a list of unconnected text things. You can do better than this.

As it stands UC journal users must scroll back down the page and take a guess from context alone what the entry refers to. How much easier would this be if things were grouped with or threaded under related content?

When you reply to something in the UC Journal, your reply is added to the top without any indication of what you replied to. The same is true of the replies from the UC person responding to you. This renders the entire journal almost impossible to use to keep track of a conversation thread.

Modern email clients solved the threaded discussion issue a long time ago. Replies are grouped with the email they are replying to. Thus the conversation thread can be followed. We do this in forums, and in comments, and on social media. Topic threading is not even remotely new.

That’s not even the only way to do things. There is also object grouping. An object can be a task, a record, a question, a ticket, or whatever. All content generated is assigned to an object. For example, if I open a ticket with my ISP about an issue I am having, we can both see what the issue topic is and the history of the conversation along with any actions taken.

On a blog, the post is the object and the comments, replies, and mentions are listed under it. Thus we know what the response was responding to. Forums do that too.

Look how easy this conversation is to follow (no tables used):

I cannot grep this logfile (where’s the flippin’ search option?)

The Universal Credit Journal system reads a lot like a poorly implemented log file. That’s how we store debug information when doing things like testing (which should have caught the deformed page on reply bug before it went live).

Grep is a command line utility for searching text-based log files. I’m using it as a nerdy way to signal to my fellow developers that the UC Journal needs a bloody search box.

Attachments as standard

A good CRM has attachments as standard. Even log entries are attachments. How this works is every entry is a small text field. It only needs to be large enough to summarise what the entry is about. If there is a lot to say, this is stored as a text attachment with metadata indicating that it is a native note (or whatever). That metadata should have some sort of document type indicator so the CRM knows if it is an image, a PDF, or note, or whatever.

Email solved this issue years and years ago with Multipurpose Internet Mail Extensions or MIME types.

HTML solved this with content-type headers like this:

Content-Type: text/html; charset=UTF-8
Content-Type: multipart/form-data; boundary=something

Other departments (especially those giving out grants) do this already. Maybe ask another department to lend you their developer for an afternoon and copy their homework.

Even if you only allow uploads upon request, using an attachment feature would allow agents to add helpful and informative media to a journal. Attachments would also allow long entries to take up as much space as a short one until clicked.

Make questions their own content type

User questions should not be an unspecialised text entry. They should be of type “question” with metadata showing who has handled the question or the agent responsible for the question. The reply should be of type linked-entry so the user can find the question and the answer together in their journal.

This would speed up handling questions as stock answer libraries can be grown so standard answers to common questions can be given in just a few clicks.

You could separate technical support questions from UC advisor-type questions. It is likely you could separate out more question types with enough use case data.

You might even want to make the question a knowledge base search that the user must check to see if said article solves their question before they ask it.

This is pretty much a standard thing in even basic CRM systems. UC needs this too.

Auto-link tasks

It should be impossible for the system to add a vital task (do this or lose money) without making the task a link to the place where said tusk must be undertaken.

Autolink your CTA’s please DWP. You do it for appointments (even if you do wrap a link around a pre-tag for no good reason. That’s not what pre-tags are for but that’s another story.)

Stop misusing HTML tags

Actually, no. This is important. Some tags have very specific meanings.

The pre-tag suggests that the text is preformatted. Usually, this is for code and other times when whitespace (space, tab, etc) must be preserved in the rendering. Screenreaders will struggle to deal with your weird HTML tag abuse. Which may (NAL) be in breach of disability laws.

pre tag used for some unknown reason

The pre-tag increases what is already a broken and inconsistent way that HTML handles white space characters (tab, new line, space, etc.). The pre-tag semantically insists that the white space is all significant even though a “bug” in the pre-tag implementation means empty lines at the start and end are collapsed or ignored. Either way, the DWP should not have client-critical architecture that depends on a mistake that could be fixed at some future point.

Here is a long article explaining just how crazy HTML whitespace gets. DWP’s dev’s please read it and understand it. If that is too hard, here is an expert reading the article and explaining it. The video is almost an hour long.

There’s no need for abusing tags in this way. It is asking for bugs and possible accessibility problems. After all, every space (meaningful or not) has just been declared meaningful in a way that can only be fully understood by also reading the site’s CSS. Use a div-tag and a monospaced font if you must but leave pre-tag for white space preserving data.

Why I think the DWP uses pre

After some poking around, I think I have worked out why the dev used the pre-tag. It’s a terrible reason and shows they don’t actually know what they are doing.

Block-level elements (which they want for styling reasons) break the table by force-resize (a lesser-known Jedi power) by making the link box element expand to take up as much space as it wants. Rather than CSS styling it to wrap, they depend on the text-wrap-mode: wrap as the pre-tag‘s default behaviour rather than setting that value in the CSS for the block. They would not have had this problem had they not used tables for layout.

If this is the case, the developer who was hired to make this website lacked anything approaching modern web design understanding and possesses barely functional development skills. I was able to identify all of these faults without even seeing the code. If I get my hands on the code, I expect unreadable spaghetti programming.

Show/Hide metadata

When reading log files (which is what the journal resembles) it is often helpful to use a tool to hide verbose information. In this case, date, time, and author should be elements the user can minify or hide. This would aid reading comprehension.

Show/Hide completed

Cancelled appointments, stuff the user or agent marks as complete, and old “you did the thing” journal entries should be something clients (users) can opt to hide. That makes getting to the critical and actionable entries so much easier.

Inbox Zero is a thing. Embrace it.

Critical actions should not be hidden in a log file

Critical activities that have yet to be completed should be more prominent. There are a number of good ways to do this.

Style to highlight: Add a “critical” class to the containing element of the journal entry that has the critical instruction. Use CSS to style it with a colour indicating urgency. Traditionally, this is red.

Dynamic banner notices: Use some JavaScript to parse the journal for classes marked critical and add a banner to the top of the page to strongly notify the user that a critical action is needed. It is only critical if not doing it costs money or risks sanctions. Everything else is at best urgent.

Critical messages set to app global: Put the critical information on all pages until undertaken.

Land the user on the page: Make the first page the user sees when logging in, the page where the critical action must be done.

Marked-up appointments to work with calendar apps

I’m not asking that you allow people to add Google Calander or other task management systems as guest apps but could you at least mark up appointments with h-event or hCalendar microformats?

Given the aim of UC is to support people, making things like appointments and to-do lists something they can export to their productivity software would make the UCW much more helpful.

If that’s too much hard work, an “add to Google Calendar” button would be something. If you are doing that anyway, why not go the whole way and make export appointment a fully working feature?

Show the next appointment prominently

Talking of appointments, like the critical actions, the client’s next appointment should be displayed prominently or at least have the option to do so. Top of the page or a toaster notification when they log in.

Push notifications?

Users should have the option to enable push notifications. These are little pop-ups that appear to tell you there’s a new message to read. Most phone apps do this and some news websites do too.

While I strongly suggest push notifications MUST be opt-in, they could prove highly useful for users of the UCW. You could further expand this to remind about appointments and urgent critical tasks that are running out of time.

You want people to use your atrocious website regularly, right? So why not prompt them to come back when something new needs their attention?

Why is this not a basic app?

The DWP need to have there (soon to be improved I hope) UCW as an app. At the very least as a dedicated one-site browser which can be knocked up in a few hours.

A dedicated UC app could provide an additional layer of protection (not only from scammers) by making the app a two-factor auth code generator. This is slightly more secure than texting a code as a text can be intercepted and is not encrypted. This, of course, depends on the devs knowing what they are doing – something I doubt from the table and pre tag abuse on display.

An app would ensure users get push notifications on their smartphones.

An official app would make scams harder to pull off.

The problem at the moment is the incorrect use of whitespace affecting markup. Apps for Apple and Android are quite likely to handle whitespace differently. You’re already borking things with pre-tags and tables. Thankfully, a few hours of reading up on CSS and adaptive design should fix those errors.

Don’t gamify just yet

I was going to suggest you have a points-based system to indicate completeness and progress. We call this gamification and it can help encourage users to be a little more active.

However, you cannot even roll out a simple CRM so I do not trust you to gamify it.

A wild guess (contains mild politics)

I have no evidence (thus this is a wild guess) but I would not be surprised if this site was not commissioned under a “cash for mates” program during the Tory administration. I would not be shocked to learn that someone got a lot of tax-payer money in their pocket and then hired an intern to knock out the system In an afternoon.

This would explain the way the UCW does not follow standard government website standards as well as why exactly I found so many instances of mistakes I would expect from a complete beginner.

Summary of fixes needed on the Universal Credit website

In this section, I use industry-standard language and so: Bug indicates something that is wrong, broken, or in error and so are critical items. Enhancement indicates something that can be enhanced and so are urgent items. Feature Request is a thing the site is not doing but probably should and should be addressed at the next development meeting (assuming you have those). I’ve also added action points for the managers to do at start of business of the next working day.

  • Bug: Deformed page on reply
  • Bug: The Journal HTML may breach the law – reevaluate concerning accessibility standards
  • Bug: The journal is not responsive but should be (for smaller screen sizes)
  • Bug: It is impossible to cancel an incorrectly started task.
  • Bug: Using pre-tags for word wrap is an error use CSS
  • Bug: Switch tables to responsive divs – should fix most bugs
  • Bug: Some key tasks do not auto-link. Consistently auto-link required tasks
  • [new] Bug: Markdown weirdness
  • [new] Bug: Missing data validation – 1/1/1111 is treated as a valid date.
  • Enhancement: Use semantically meaningful tags
  • Enhancement: use syntactically appropriate language
  • Enhancement: Make critical messages more prominent
  • Enhancement: Add toggle hidden for metadata
  • Enhancement: Add toggle hidden for expired, cancelled, or old entries
  • Enhancement: Add microformats to make data more useful
  • Feature Request: Search feature
  • Feature Request: Threading, ticketing, or task-object grouping
  • Feature Request: An attachment system
  • Feature Request: Add a question entry type with a linked answer
  • Feature Request: Enable clients to add appointments to personal calendar apps
  • Feature Request: Optional push notifications
  • Feature Request: Make a dedicated app
  • Action point: Hire a domain-expert systems analyst who will confirm everything on this list.
  • Action point: Read the analyst’s report and action it ASAP.

Alternatively, dear DWP managers, put together a budget to hire me and a small team I will select – we will fix it for you; budget for ongoing development as the UCW could be so much more than it is. You got this expert analysis from me for free which is already a massive saving. Make the most of it.

Over to you, dear readers

I think I have covered every fault with, and improvement needed for, the DWP’s Universal Credit Website. Is there anything I have missed? Are there more bugs to report? Would you like an enhancement I’ve not mentioned or hate one I have suggested?

I want to know your thoughts. Don’t send me a comment, leave me one. Or a reply via federation, or a WebMention via whatever content publisher you use. I really like comments so please leave me some.

Your replies will not be shoved inside a table and no pre-tags will be harmed.

Tags: / SetUpToFail No Comments »

Blog Activity