As of right now, a brand new LEGO Universe News! Patcher is available on the LEGO Universe News! Forums (LUNF) homepage. For those of you who do not what that is, it is basically a news widget containing an RSS fees from LUN, a YouTube embed player (the HTML5 one no less) of a hand-picked LEGO-related movie, and links to important parts of LUNF (such as the rules).
Note: This post is very technical, with “lots of filler, complex terms, charts, and graphs”. It may be best to have the Patcher open while reading to gain context.
The name “Patcher” comes from LUNF history. About three and a half years ago, Supersoradude (AKA Legofan101), the founder of LEGO Universe News!, commissioned the creation of a news widget designed in the style of the then-current (and alive) patcher for LEGO® Universe, the first LEGO MMO. It was a big hit, containing all the features possessed by its successors but using different technology (such as Adobe Flash player and an long-forgotten video player.) It’s sudden removal some months later was confusing to many, to say the least. It was then replaced with the actual LU patcher, albeit broken (How Sora got that there in the first place is still beyond me). After the forum administration was changed over to rioforce and Hobino a good year later, the broken patcher (even more so now that Universe was closed) was removed and the creator of that original Patcher was again asked to make a Patcher like the original, which they kindly did. Some months later, a brand new Patcher based on a more recent version of the LU patcher was created by rioforce (spurred on by Hobino’s want of a new one) featuring the same features but implemented differently (I described those features at the very beginning of this post) and has been in use for 6 months with some revisions.
For two weeks in December 2013, I worked on upgrading the Patcher to utilize HTML5 and CSS3 technology, allowing new updates later on and bringing it up-to-date in the world of Web design. However, I cannot post technical details on LUN, so I’m posting them here. 🙂
The Patcher was originally designed using a visual site creator, which helped make a good design but bad code. (Side note: I am all for visual site editors to help the non-coders get a decent site up and running, and even designers to get a good foundation and manually update it afterward. They are good and I do support their usage, but they can create some messy output, as you are about to see.) External CSS stylesheets were not used, rather everything was inlined and/or in-element. In addition, the feed was displayed using an
iframe‘d HTML page, and the video player was an HTML page containing an
iframe that was
iframe‘d onto the main page, so a double
Work Guidelines and Goals
Since I was not planning on making a brand new Patcher or rewriting it from scratch, I laid out a few guidelines and goals.
- Use HTML5, some CSS3, jQuery, and possible jQuery plugins
- Follow best web site design practices
- Clear out all superfluous code
- Keep the same UI design, but tweak where possible
- Use a better RSS feed client
- Responsive design for better mobile rendering, as requested by rioforce
- Keep it fast
I did my best to divide the work into steps, but as any developer knows nothing really happens that way. 😛
- Obviously I started with using the HTML5 doctype (upgraded from the transitional HTML4 and HTML5 one), any important changes in the
<head>, and the addition of new resources, such as jQuery.
- Next came cleaning out the superfluous code and tags (
<area>tags and JS for IE 6 support anyone?) and offloading the inlined CSS.
- I replaced the background image with a look-alike
linear-gradientand moved the in-element CSS to the stylesheet. Though I list these actions near the beginning, they actually overlapped with other actions later, that is, this was going on in addition to the other changes being performed.
- I replaced, removed, and reordered tag attributes according to the HTML5 spec and personal preference.
- I abolished the awful double
- Any PNG images I was not removing or changing as well as new ones was compressed twice using PNG Monster, which does utilize the near-universally recommended PNGOUT utility.
- I replaced the three main buttons (FAQ, Rules, Staff) with plain text instead of images. They and other text are displayed using the Nunito font from Google Fonts, Arial as a fallback, and sans-serif as a last resort.
- The RSS feed replacement turned out to be one of these hardest things to change. Previously, we used the FeedWind.com service, but it was more of a last resort back then. I turned to a Google Ajax “Feed Control” we used for a short time but that turned out to be a huge resource hog. In addition, I was unable to set the feed link’s
targetattribute to the mandatory
_blankvalue (this is why we used FeedWind). I finally found the excellent FeedEk jQuery RSS/ATOM Feed Plugin, which is lightweight, customizable in both styling and options, and required no dependencies except jQuery. There are a few bugs in it, but nothing major or limiting.
- The background image originally displayed a message stating the video could not be played on that particular device with the LUN logo above it. Normally this is covered up by the player, so if the player did not load for some reason this message was visible. I did my best to recreate this in text but player positioning made it hard to do. Right before finalization I replaced it with an image of the same message.
- Because the RSS feed area can only display so much, I made us of the perfect-scrollbar and jQuery Mouse Wheel plugins to create a custom, cross-browser scroll bar. I was already using these great plugins in another as of this writing unreleased web project, it was a no-brainer for me to use them again. Again, small bug here with the scrollbar not completely calculating the proper size of the RSS feed, but not much I can do about that (and nobody expect one perfectionist has complained :P).
- I cannot forget the endless tweaking of positions, sizes, margins, whatever could be adjusted for better display.
- At the top of the news feed is a small image stating the feed source. This was updated and replaced with pure text.
- Because the Patcher is actually open-source (licensed under The MIT License) and hosted using GitHub Pages, I was able to test cross-browser and cross-platform compatibility tests as I worked, not to mention performance tests.
- Throughout the entire two weeks, any unused and unneeded files and folders were removed, as well as rearranging the location of certain important files (an example would be moving
index.htmlfrom a subfolder to the root).
- Per a highly last-minute idea by rioforce, I added a check for Internet Explorer 9 and below to redirect to a relocated copy of the previous version. This was done because those versions do not support the new HTML5 technology I used (I already had to add a
-webkit-vendor prefix for iOS Safari because it does not support
- Even after merging v2.0 into the original repository (I did all this on a fork), I made small adjustments to the player location, perfect-scrollbar, and minor bug fixes.
You may quickly notice the lack of any mention of a responsive design while I completed all other goals. This is because I do not yet have the knowledge and ability to perform such work. While I eventually may upgrade the Patcher again which such abilities, as of now it is not yet possible. In addition, this would not seem to even benefit from a responsive design, at least to me.
The results of my work came out rather positive. Overall, the upgraded Patcher outperformed it’s older sibling in almost every metric.
- Original, IE 10: 2.360s using 26 requests upon first visit, 0.867s upon second visit using 3 requests
- New, IE 10: 1.950s using 22 requests upon first visit, 0.337s upon second visit using 4 requests
- Original, Chrome: 2.752s using 27 requests upon first visit, 1.026s upon second visit using 4 requests
- New, Chrome: 2.006s using 22 requests upon first visit, 0.982s upon second visit using 9 requests
Google PageSpeed Insights
As I said, it out performed in nearly every metric, not every metric. Judging purely by speed tests, it can be said the new Patcher is slower than the old Patcher. However, speed tests do not count for everything. Usability, ease-of-service, modern technologies, and general betterness (ha, not a real word 😛 ) cannot be measured in speed tests. It is in those metrics the new Patcher shines, if I do say so myself. 😛
We have finally reached the end of this post. Sorry if I bored you a bit, and I won’t nag if you fell asleep someone during it. 😛