Experimenting with Mobile First Design
For the last couple weeks I have been working on a small project called Knave App. This application is not finished quite yet, but it’s in a usable state and I wanted to talk about my experience designing and coding it and what I learned.
As always, I’d love to hear some feedback. Comment here, or reach out to me through email, Twitter, or my LinkedIn, or find more of my work at my portfolio or GitHub,. As of the writing of this article I am actively looking for work. Don’t hesitate to reach out if you’d like to get in touch concerning an employment opportunity.
Why I Made This App
I wanted to get some practice making a mobile web application. As silly as it might seem, I specifically wanted to try my hand at making a nice slide-out drawer menu. I just think they contribute so much to a pleasant user experience on mobile, so I thought it would be beneficial to learn how to do.
As for the content of the site, I am also a fan of indie role-playing games. Knave is a really neat little game whose content is open source. I saw someone else’s online Knave ruleset and thought I could do it better. All I really thought it needed was better navigation, and thus the perfect content for my mobile web application was presented to me.
How I Made This App
I copied the ruleset word for word, spent some time formatting it in HTML, and spent a good deal of time styling it to make it perfect. The slide out drawer has links to the major sections of the ruleset. I went with a cream background with dark grey font for the easiest reading experience (and it shouldn’t take much to implement a night mode). I used an SVG icon for the menu icon in the upper left. I think I’ll be using SVG icons from here on. They’re easy to style and easier to work with than unicode text (which is what I used for the menu icon originally). They also have a consistent appearance across browsers. I added a couple extra bits of functionality — one for rolling a monster reaction, and one for rolling a random spell.
I originally wrote the drawer’s open and closing functionality using native JavaScript touch events before eventually switching to HammerJS. I added event listeners for the ‘touchstart’ and ‘touchend’ events to the body of my document. This ‘touchstart’ event set the starting x and y coordinates of the touch using
x1 = event.changedTouches[0].clientX
y1 = event.changedTouches[0].clientY
And ‘touchend’ set the final x and y coordinates of the touch using
let x2 = event.changedTouches[0].clientX;
let y2 = event.changedTouches[0].clientY;
I then calculated the difference of the beginning and ending x coordinates. If the difference was greater than a threshold of 60 pixels (the user swiped right), the drawer opened. If the difference was smaller than the negative of that threshold (the user swiped left), the drawer closed.
This method worked but was not perfect. If the user swiped vertically and happened to move too far left or right the drawer might open or close. If they swiped with the intent of opening the drawer, they would inevitably swipe up and down a bit, which made the swipe motion feel clunky.
I soon realized that, even though I wanted to write my own touch functionality, I would save loads of time using an external library, so I implemented HammerJS. HammerJS is as simple to use as vanilla JavaScript touch event listeners but has added functionality. HammerJS solved my vertical scrolling issue during right swipe by only listening for a horizontal swipe, not just a touch — so if a touch started vertically and happened to move horizontally, it would not cause the drawer to open or close. This, combined with moving the listener for the beginning of a touch from the body element to a dedicated element that’s about 10% of the screen’s width and restricted to the left side of the screen, gave my application a much nicer, more native feel.
Side note: Switching to HammerJS caused an issue that I cannot seem to fix. On Chrome mobile, swiping the drawer open seems to remove the ‘click’ event listener from the menu items for about half a second, or it for some reason is taking 2 clicks for the event to register. This only happens on Chrome mobile, not on Firefox. I traded one issue for another this way, but I think this is a smaller and more fixable issue.
How I Learned From This App
I think there is something to be said for trying to do something on your own before using a library. I’m still trying to find the balance between leaning on libraries and learning something myself so I understand it better. I think if I had a deadline on building this app I would have utilized HammerJS sooner. But I’m happy I spent time learning about JavaScript’s touch events. I like how bare-bones they are, how unopinionated they are.
I also learned the hard way that testing on a desktop browser’s mobile inspector is NOT the same as testing on a real phone. I spend multiple short days trying to figure out why on FireFox Developer Edition on Mac, elements with the style
position: fixed;
top: 0px;
Would sometimes randomly move from where they were supposed to be (hovering somewhere outside the normal structure of the DOM tree) to the very top of the page. After wracking my brain over this for a few days, I finally pushed this apparently broken code to the live version of the site only to see that the issue was non-existent in production. A lot of time was wasted this way and a valuable lesson was learned.
I also thought a lot about the difference in production time between using React versus native HTML/CSS/JS. React would have been a lot faster to develop with, but would unnecessarily increase the project’s size. Using HTML/CSS/JS is great for learning more about the basic technologies all web developers use, but boy howdy is writing HTML with JavsScript, or HTML on its own, more time intensive than writing React components.
