Raise the Hammer
The website for meeting agendas sucks. It gets almost everything wrong, from proprietary technologies to obsolete, inaccessible formats.
By Ryan McGreal
Published April 08, 2014
Since 2011, the City of Hamilton has contracted with a company called SIRE Technologies to record and stream Council and Committee meetings.
The technology package the City received from the company included the ability to post meeting agendas with associated reports and other documents. However, until recently the City used its own existing website content management system.
Then, in mid-March, City staff started using the SIRE Technologies system to host meeting and documents. I first noticed the change when writing about the Cannon Street Cycle Track, which the General Issues Committee considered on March 19.
I was no longer able to copy the URL (the website address) for a document from the GIC meeting page and share it in an article on RTH. When I tried to copy the URL of a document, I got a URL that would expire and stop working shortly after I had copied it.
Instead, the best I could manage was to link to a clumsy links page.
Aggravating as that is, it is only one small part of what is wrong with this service. To put it bluntly, the website sucks. It gets almost everything wrong, technology wise.
The SIRE website employs obsolete and bizarre web design decisions to make for an awkward, inaccessible user experience.
Specifically, it uses HTML frames: each HTML page is a container with other HTML pages inside it. HTML Frames are an obsolete format that have been almost universally abandoned due to poor usability:
Clicking on a link causes unexpected behaviour, e.g. having the link open inside one of the frames instead of in the full browser window.
It is not possible to save the current state of an HTML frame set in a URL that can be shared with others.
HTML frames perform poorly in screen readers (for blind web users) and mobile browsers.
Frames are hard for search engines to crawl and index, so content becomes harder to find.
Frames break the Back button, which is a core navigation tool, and can leave users lost and confused.
In the 1990s, when many websites were composed of HTML text files, frames seemed like a way to make it easier to update content that appears on every page of a website - like a menu - by storing it in a single file that every page includes. (The first website I ever built, in 1999, used HTML frames.)
However, other superior methods of storing shared content have since rendered frames obsolete. Most websites today are generated by a dynamic content management system that can handle changing content that appears across various pages.
The SIRE website itself is built on a dynamic web page framework, so it is really unclear why they also decided to use frames.
In addition to the various ways that HTML frames break URLs, the site employs a cumbersome URL pattern that makes it difficult to understand and navigate.
A website's resources are supposed to be stored in a hierarchy of URLs in directories and subdirectories, with the base website accessible through the root URL. This allows website visitors to navigate up the hierarchy by changing the URL to remove layers from the path. But if you try to visit the base URL for the Hamilton subdomain, http://hamilton.siretechnologies.com/, instead of a main page you get a login form to administer the site.
Likewise, instead of clean URLs, the site exposes its underlying technology (Microsoft ASP.NET) in the file extension (.aspx) and defines individual resources via a querystring parameter. For example, the URL for the March 19, 2014 GIC meeting is http://hamilton.siretechnologies.com/sirepub/mtgviewer.aspx?meetid=588, whereas a cleaner, more portable, longer-lasting and technology-agnostic URL would be something like http://hamilton.siretechnologies.com/meeting/588.
Worst of all, links to individual documents associated with a meeting can no longer be linked directly. This is literally the most basic function of a website - to provide URLs that link to resources on the website - and the SIRE website gets it brutally wrong.
Again, using the example of the March 19, 2014 GIC meeting, you might scroll down the frame on the left (with the agenda) to item 7.3, the Cannon Street Bi-directional Cycle Track Pilot Project (PW14031) (Wards 1, 2 and 3).
If you click on that link, it opens the content not in the browser window but in the HTML frame on the bottom right side of the same page in a frame titled "Supporting Materials". It includes links to four files:
Of course, the text of the titles is not linked; that would be too usable. Instead, you have to point your cursor or tap your finger on the tiny PDF logo to the left of the titles.
But it gets even worse. If you click one of the document links it redirects to a URL with a long "cache" string in the address. It works for a little while, but then seems to expire. Subsequent requests to the URL result in a Not Found error from the server.
The SIRE website uses a proprietary browser plug-in, Microsoft Silverlight, to stream the video. This is a very poor technology choice, for several reasons:
Silverlight was meant to compete with Flash, an older proprietary browser plug-in that has an established market share. Because Silverlight failed to make significant market inroads, Microsoft indicated after releasing version 5 in 2011 that the technology is now deprecated and will no longer be actively developed.
Silverlight does not work on mobile devices on either the iOS or Android mobile platform. It doesn't even work in the browser on Microsoft's own Windows Phone devices!
It barely works on computers running the Linux operating system, using an independently-developed open-source implementation called Moonlight, which is no longer in development since Silverlight itself is not in wide use.
A much more reasonable choice would have been to serve content using HTML5 video with a fallback to Flash, rather than a technology that is not only proprietary but also marginal in both platform reach and market share.
More generally, the SIRE website uses expensive, proprietary Microsoft technology instead of the free and open source software that powers the Web. Most websites, including most of the 10,000 biggest sites, run on a stack of technologies that are licenced such that anyone is free to use, copy, read, modify and distribute the source code.
Free and open source software dominates the web because of its many net benefits. Since everyone can access the source code, desired features are added in a timely fashion and bugs and vulnerabilities are quickly found and fixed by security analysts.
Mature free and open source software, like the tools that power the web, are supported by strong communities of technology professionals and are stable, robust and secure.
The alternative is to use proprietary, closed-source technology - software what was written by a company and provided for use in a way that prevents third parties from reading the source code, let alone fixing it. Proprietary software must be purchased and licenced under restrictive terms of use, making it more expensive and less adaptable.
Instead of the confidence that comes from open peer review of free and open source software, proprietary software must be used with blind trust of the company that controls the source code.
Instead of the ability to contribute to the project to add desired features or fix bugs, proprietary technology users must depend on the company that owns the code to do this or simply accept that the company has decided not to.
| Free/Open Source | Microsoft | |
|---|---|---|
| Operating System | Linux | Windows Server |
| Web Server | Apache, nginx | IIS |
| Database | MySQL, PostgreSQL | Microsoft SQL Server |
| Website | PHP, Ruby, Python, etc. | VB, C#, F# on .NET |
With open source software, if the community supporting a project dissolves or abandons it, another organization can take it over and keep the project going. With proprietary software, if the company that owns a project stops supporting it, the project shuts down and its users are left unsupported.
RTH contacted the City to ask who on earth decided to go with this technology, and what criteria they used to make the decision. We were directed to Jay Adams, a Service Delivery Experience Advisor for the City. I am given to understand that Adams wasn't responsible for the decision to use this technology but was left with the fun task of explaining it.
Adams stressed that the tool to manage agendas and documents is already included in the streaming service from SIRE and the City did not have to spend additional money to start using it.
According to Adams, using this service instead of the City's existing content management system "will enable faster publication of the materials to ensure citizens receive the information as quickly as possible."
However, he acknowledged that the technology has some serious accessibility and usability problems, including the broken document linking. "We will be taking urgent steps to restore easy access to these materials as quickly as possible."
City staff do not appear to have done any community consultation before adopting the SIRE system. If they had, they might have learned about these problems - and gotten a better sense of how such a system should work - before rolling it out.
By Selway (registered) | Posted April 08, 2014 at 10:10:39
Um. Shouldn't the city staff who bought this service have known the basic background which you discuss before going shopping in the first place?
If Mr Adams was not involved in the decision to purchase, who was? Is there an RFP on file in Purchasing? Assuming one could find it...
By Pxtl (registered) - website | Posted April 08, 2014 at 10:14:15
Oh gosh, when I saw the .aspx I was horrified to think it was Web Forms... but then looking under the hood in the markup, it looks like they're at least avoiding the ASP.Net webcontrols and doing pretty vanilla dynamic HTML... albeit hideous html with nested tables all over the place.
That said, this sort if simple .NET-based dynamic HTML would probably run just fine under Mono, so without the Silverlight dependency it probably could run under a free/open-source platform. And realistically, the city is paying far more for whatever hideous contract Sire Technologies has them under than any software/server costs to Microsoft for licenses.
Then again, probably modern ASP.Net MVC would run better than this on an open stack since MS has gone open-source with their MVC framework.
Comment edited by Pxtl on 2014-04-08 10:15:32
By mikeonthemountain (registered) | Posted April 08, 2014 at 10:36:10 in reply to Comment 100024
A shame and a waste of potential, but funny. I always believed that Presto is also using Microsoft technologies for its systems as well, what with that system being unnecessarily complicated, clunky, and expensive.
Presto and GO are ASP webforms sites as well, Microsoft seems to be what government uses. But GO is champ for having an android app. We should be a well connected city by now, is what I thought last time I checked for an HSR BusCheck app on Google Play and found none.
By Jonathan Dalton (registered) | Posted April 08, 2014 at 15:01:30 in reply to Comment 100026
I don't know about the Android app, but when the official GO Transit app came out for iOS, it was worse than the 3rd party app (GOToronto) that had existed for years and continues to be updated. For example, you must choose either train or bus schedules, even though many routes use a combination of both. On the old app you pick a route and it shows you all available departures by train or bus. The Metrolinx app also forces you to scroll through a long list of stops to find both your origin and destination - no option to type in the first few letters to find it quickly. It's sad to see our tax dollars wasted on something the private sector (actually, just one guy) has done better and cheaper.
By MattM (registered) | Posted April 08, 2014 at 13:20:38 in reply to Comment 100026
A bit off the topic but there is an app called "Transit" that works just as well as an official HSR Transit App would, and it also works for most of the other GTA systems (Hamilton, Burlington, GO, MiWay, TTC). It's available for both Android and iOS. It pulls schedules from the HSR's public GTFS feed, so they're pretty much always accurate. Unfortunately the HSR hasn't made their real-time bus positioning data available for public use but when they do, the app will support that too.
(don't have anything to do with the app, just really frustrated that the HSR hasn't provided anything of their own and wanted to be helpful to those looking for a mobile solution)
By mikeonthemountain (registered) | Posted April 08, 2014 at 13:26:41 in reply to Comment 100033
Nice, thank you for sharing that! Had no idea this existed.
By Pxtl (registered) - website | Posted April 08, 2014 at 10:46:56 in reply to Comment 100026
checks prestocard.ca source
Ahhh, there's the painful world of ctl00_moreconainernames_ctl01_etc that I remember and loathe.
Microsoft gets a lot of rage they don't deserve, but foisting ASP.Net webforms upon the world is definitely one of the ones where they earned every ounce of it. It's one of those technologies that would have completely bombed if it was released by a 3rd party or an OSS team, but survived in barely-functional zombie-like existence because it bore the Microsoft brand. It's a shame, since there's a lot to love in the MS .NET programming stack, it's just that their first stab at websites on that platform was such a trainwreck.
By mikeonthemountain (registered) | Posted April 08, 2014 at 11:01:52 in reply to Comment 100028
Oh my, I totally concur. Trying to make really good Ajax app in .NET4 with AjaxControlToolkit was incredibly stressful and unpleasant. As soon as I started nesting controls, all hell broke loose. Those frameworks could not handle a true web2.0 responsive app unless they are really really simple sites. I am truly grateful it didn't cost me my job.
Doing the same project on a LAMP with jQuery driving the Ajax is such a pleasure. My heart is totally in the non-MS projects, some of which are very exciting right now. I would be happy if I never worked on another asp site in my life. Unfortunately I have some work to do on our Sharepoint site, but I'll suffer it because I have to :)
Comment edited by mikeonthemountain on 2014-04-08 11:02:20
By Pxtl (registered) - website | Posted April 08, 2014 at 11:15:42 in reply to Comment 100029
.NET4 with ASP.Net WebForms should never happen. WebForms is unofficially deprecated (unofficially because MS will never admit that they made a technological dead-end). Modern ASP.Net should be using the MS MVC framework, which eschews the whole nested component model in favour of being more like a C# version of Ruby on Rails (albeit with a few warts of reusing the underlying Asp.Net framework).
MS has actually gotten good about running some of these tools as OSS projects in recent years - MVC, Entity Framework (their ORM) and now the C# compiler itself are now being run as open-source projects that even accept patches from teh public. ASP.Net Web Forms is an artifact of the "GUI designers and wizards for everything!" period of a decade ago, but modern .NET is actually pretty good.
And yeah, Ajax Control Toolkit is a source of pure unending pain. Holy crap what a mess.
Oh God, you have to extend Sharepoint? You have my sympathy.
Comment edited by Pxtl on 2014-04-08 11:16:17
By mikeonthemountain (registered) | Posted April 08, 2014 at 11:32:17 in reply to Comment 100030
When that project was on, MSMVC was in a pretty early version and I had not learned it yet, or even heard much about it. I came from a background of writing windows apps before that.
Since then I started learning MVC4 in earnest, with jQuery. It is so much better. You can actually achieve clean markup output. Very easy to learn too if you already understand each core concept. If I have to do an MS site in the future it will be MVC. I guarantee I'm done with web forms, totally obsolete technology anyway so it's moot.
However I've moved away from writing MS web apps altogether, and do them in other frameworks now. The focus shifted pretty dramatically. For the better. I enjoy the work more now, and can spend more time exploring the cutting edge of what browsers can do, while still keeping things very clean.
In government, on the other hand, such things tend to move much more slowly, and many managers stick with what is familiar to them, don't they. And so, whether city website, or regional fare card, we get clunky things that barely work and drain the public purse more than necessary. Too bad.
Comment edited by mikeonthemountain on 2014-04-08 11:39:15
By NoSugarAdded (registered) | Posted April 08, 2014 at 13:38:24
As someone who works for the city, I can tell you that someone at the cities IS/IT department in in love with Microsoft. That is all they use for the most part and won't allow anything else. You cannot even us Chrome or Firefox on a city computer.
Aggravating as that is, it is only one small part of what is wrong with this service. To put it bluntly, the website sucks. It gets almost everything wrong, technology wise.
Frames, .aspx, proprietary graphic technologies. Obviously you just don't get it: it's a heritage web site.
Don't you appreciate the city spending tax dollars to keep some of out heritage alive in this rapidly churning on-line world?
By adam (anonymous) | Posted April 09, 2014 at 01:39:00
I think the whole lamp vs ms stack argument in this article is nonsense and is just the author's opinion / prejudice. It won't matter a bit to the end user what backend is being used.
The argument against Silverlight is valid and URL/ broken link criticism is warranted.
You must be logged in to comment.
There are no upcoming events right now.
Why not post one?