As most of the web development for the Caves of Narshe is a one-man operation, I admit that the site can be slow to adapt to trends. Most recently, that trend has been responsive web, which is particularly annoying given that the site's core competency, video game information and walkthroughs, lends itself extremely well to use on a mobile device. Most games now are played with the user either on the mobile device itself, or with the phone or tablet sitting next to them as they play from the couch. A hard-to-use UX for mobile makes the site itself less attractive to players, which makes the site get less traffic as the mobile market slowly swallows the desktop market. Not only that, it also makes the site less discoverable, as Google gives its mobile users results first that meet the search criteria and are also mobile-friendly. Nobody wants to be lacking that badge of honor.
Requirements
The goal here was to make the CoN site mobile-friendly, with a baseline of being usable on most modern mobile devices and avoiding any Google search penalties. This does not necessarily mean that the site should follow all best practices around responsive design, nor that it should be a better or even equal UX to the desktop site; the goal is merely to make the site legible, functional, and Google-approved.- The site should be branded as closely to the desktop version as possible without causing undue payload burden on the user.
- All of the primary features of the site should be functional and easily reached: game content, news, discussion forums.
- The site should render well and be legible on devices all the way down to the iPhone 5.
Limitations
The site had never really been designed with responsive content in mind; however, before "responsive" was any kind of a buzzword, CoN was a site designed to fit various screen sizes. Focusing on what was once called "fluid" design, CoN had developed the basics of being responsive for larger devices way back in 2000, back in the day where your options for screen pixel dimensions were mainly 800x600 and 1024x768. Because of this, I set upon myself a limitation that this should not be a separate site skin served up just to device users, but instead a take on the site's current default skin, called "Skyglade," which was released in 2012 with a fluid design that worked well for desktop monitors of any modern size. Setting this limitation gave me a place to bolt in my aftermarket parts to improve the site's responsiveness, while also giving me an easier path toward requirement #1. This brought on a further limitation that the implementation should make it difficult for users to change site themes on mobile devices, allowing me to focus on Skyglade while avoiding painting myself into a corner where I would need to create mobile-friendly versions of all the themes in existence.
Implementation
This was a UX-only project; all of the back-end and middleware pieces were already in place due to the limitations I set forth, or at least they were for the most part. Because of that, the implementation ended up being surprisingly straightforward, albeit a little hacky: first, I placed the standard meta tag to control viewport, setting the content as "width=device-width, initial-scale=1". I then took the site as it already was, emulated the site in Google's excellent emulation tools in Chrome at various common devices/device sizes, and used Chrome's inspector to begin massaging and removing pieces until the look was correct. I was able to pick away at this a little bit at a time, setting up a mobile stylesheet little by little in a new branch forked from CoN's dev repository. This sheet is referenced by the site using a single @import triggered by a single media query: (max-width: 799px).
How is it that I got away with just this one media query? It's actually a fairly simple idea, one made possible by the aforementioned fluid design. CoN already looked as desired and functioned well for screens of any orientation that are 800px wide or wider, so I made the decision to simply serve the entire desktop version of the site to those users. There is a downside to doing this, of course, and that is the fact that some of the more decorative and larger images used by the site's chrome would render on tablets - which may or may not be using the user's cellular data. This was a calculated risk, gambling that most users who would be using the site regularly from their tablet would have available wifi; it was a barely-educated guess, but it appears to be working.
Simply setting up these two things, therefore, got me a lot of quality results on various devices, but only in the case where I dropped the navigation entirely from the pages. CoN in Skyglade has two main navigational features, one at the top and bottom of the header for game content and other major sections, and a more contextual left navigation bar that runs vertically and contains links relevant to the section of the site being used (the forums already had their own contextual navigation, and as such that bar never appeared in that area of the site).
Obviously, removing navigation from the site does not improve the user experience one little bit, so that part of the middleware needed to be redone for mobile users. Additionally, a mobile device, especially in portrait mode, certainly doesn't have room for two navigational features with the amount of content needed to provide both the primary and secondary/contextual navs, so the navigation would need to be wildly different than that on desktop.
Thankfully on this score, CoN had inadvertently looked ahead as well. When Skyglade was first developed, it was developed using a custom XML schema to store navigational node data. At the time, I did this because CoN has not one but several site skins from which the user can choose, and each one previously was forced to use identical HTML markup. That markup did not work for my plans for Skyglade, and as such I rewrote that part of the bespoke theming and templating system to instead use a set of common XML files which could then be parsed out differently for different themes. This meant that I could simply call another parser that I would write to generate a completely different set of markup for the mobile nav, allowing me to drop the bigger and blockier desktop navs for a full-width, slide-down-from-hamburger-button nav that would cover the page content on demand.
Why XML, by the way? I love alternative data formats for these kinds of things, especially JSON. But, in this case, the extra syntactic sugar of having HTML-style nodes for each element made the information much easier to parse using PHP's onboard SimpleXML library, and also made it easier to develop visually when adding in dynamic pieces of the navigation, such as the user's saved preferences for hiding game spoilers, or the most recent discussion topics in the forums.
So, that solved the problem of presenting a navigation, but not specifically the problem of how to merge the two nav sections from desktop. To do that, I modified the parser further to ingest two XML files simultaneously, with the files chosen based upon the site section of the page making the request. There are several different combinations that can be output from this, but it really boils down to just two major permutations.
For pages and sections that would use the global contextual navigation normally, the output nav would first list the game guides, as these are the most important pieces of navigation for a user landing on the homepage, and as such should come first. After that, the second batch would load in the global contextual nav, which contains links to site meta-information and social media. Finally, as the least valuable navigation for users in this state, the nav would load the remaining main site sections, including the primary link to the news section, fanworks (a.k.a. fan-generated content), and so on. While these links take visual precedence on desktop, they are also reachable via other means, and as such can live at the bottom of this visual hierarchy. News is a good example of this state, as on the homepage the most recent news appears for all users no matter what.- For pages that have their own contextual navigation, which is the vast majority, that contextual navigation comes first. If you are on a page with information about the Square Enix classic Chrono Trigger, for instance, the odds are very good that the next content you want (if not linked to directly on your current page) will also be in the Chrono Trigger site section, so the user should not be obligated to swipe for screen after screen to get to it. These contextual navs can be very long, due to the breadth and depth of CoN's game coverage, so to reduce the length of these navs no other game content categories are shown in this context, replaced instead with a general link to the "Guides and Info" landing page, from which the user can dive back into a game's content. The secondary nav featuring the news, fanworks, etc. links will appear below the Guides and Info item.
Finally, to reduce the burden on mobile users further, the I instituted lazy-loading on as many pages of the site as possible. This involved adding a third-party lazy-load jQuery plugin, and altering as many pages as I could within a short time to leverage it, starting with the pages that I knew were most likely to have large numbers of images - enemy bestiaries in the game content sections and forum threads within the forums, where each user's avatar is featured. This allows users who land on a page accidentally, or on a page that they find not to their needs, to move on without the burden of possibly downloading every image on the page before exiting.
With these three things in place, the CSS and the additional nav markup, the responsive site was ready to roll out; the total time spent was under a month of intermittent work, once planned out.
Reception
Among the robots, this project was a success; CoN immediately gained the mobile-friendly declaration from Google and has kept it since. Among users, for the month before the release versus the month after, pages per session went up by 3% immediately, and average session duration went up 7.4% overall but 13% for mobile specifically. The second month, PPS went up 4% and duration up 10.1%, with mobile up 8.6% and 15.4% respectively. As always, correlation is not causation and I'm not going to sit here and run standard deviations and such to determine the statistical significance of these numbers, but on their face they look pretty solid.
Post-Mortem
I will be the first to tell you that there's room for improvement on what I've done here. I would have preferred to work from a mobile-first approach, because it's just so much easier to know your limitations when you start and then layer in the more robust desktop experience than it is to go the other direction. However, I had an immediate need for impact, and a limited amount of time to conceptualize and execute the idea, so I aimed for the biggest bang for the buck, to leverage a cliche.
First and foremost, the methodology I used to reduce the unnecessary images focuses mostly on hiding them from display. Many browsers will go ahead and load display: none images for cases where user interaction might make them visible after the fact, though mobile browser are getting better about that idea. I haven't tested fully that issue, so I don't know how bad of an impact it makes, but I suspect I won't like the answer. Lazy-loading avoids this issue, but it doesn't immediately solve the core problem for these particular images.
I'm also not thrilled with the level of branding that I was able to maintain. The branding fonts for the site are fairly generic, not like the distinctive logo, but the logo in its current form is too large both in weight and usable size to serve to phone users. I was able to maintain the smallest part of the header, but not the immediately distinctive logo and fanart that is used on larger screens.
The primary nav exists in two locations now per page, as well, because each nav is so wildly different that it can't be easily made to stand alone. The user does not notice this, but it is a bit sloppy and something worth improving to reduce the overall payload a bit.
Finally, as yet I've been unable to go back in and revisit individual pages that did not immediately snap into place with my first round of edits. There are some pages that just likely won't work well in any portrait orientation on phones, such as large data tables or most forum threads, and some mitigation should be put into place to improve their usability.
There's a reason I'm posting about it, though, and that's because even with these issues, this project nailed it. I even use the site on my own phone now without gritting my teeth, and I'm usually the last person to like what I do!
- Log in to post comments
