Creatives are a fickle bunch, aren’t we? Always changing our minds, never thinking projects are finished and constantly asking if “it’s good enough.” In today’s post, I’m going to breakdown the process of creating a new site from scratch in just a few days’ time. Here’s what went right, where I messed up, and what I’m going to do about it. Let’s begin!
To be honest, the main concept of the site had been swimming around in my head for a while, way before I had put finger to keyboard. I had seen sites that played around with the texting concept, and I wanted to take my own shot at it. I felt this would be successful for a couple of reasons:
- It’s a unique user experience
- The MVP was fairly straightforward
- It’s the same amount of clicks to get the same content as a typical website design
- It’s mobile-first (literally)
While most of these reasons are pretty easy to grasp, I do want to expand on a couple of them.
First, I did assume that this concept would be straightforward from multiple angles. The design and development in pseudo felt ‘easy,’ so to speak. However, there were a few wonderful hangups that I did not account for… such as getting the text bubble window to scroll down automatically as new texts were added, and transferring the design from mobile to desktop using the same DOM, but considerably changing what the containers looked like. Other things caught me off guard too, like what the best way to store the responses is, how to append them to the page (ended up using simple AJAX), and finally, determining what the actual content should be!
The project wasn’t without its wins though. I think a few great things happened rather unexpectedly and I’m proud of them.
One of my favorite parts of this site is the celebration button that pops up after a user has explored all the choices given to them. I wanted a way to express thanks to the player, in a simple way, for having stayed around and clicked on things.
Back when James and I were doing game development with Applied Studios, we often talked at length on ways to balance joy and tension within the games we were creating. To give a little context, most games, like many films, have a natural sort of rhythm (you could call these beats), and in games, you want to balance these beats as they are typically either situations/content that cause joy or tension. Too much of either and the game will feel boring or too hard.
To give an example of this balance, let’s consider a game like Candy Crush. The puzzle game makes players align like-colored candies on a grid. The player has limited turns to ‘match’ a certain number of candies on each level. Usually, a player will spend several turns in order to get a match — this is the tension. Later levels can be hard, and require chess-like strategy of thinking ahead in order to win. To balance this tension, the game provides, almost comedically, joyful animations when players make a match, and the bigger the match, the more animated the celebration is. Fireworks, confetti, sound effects… it’s very similar to a slot machine in a casino. And boy howdy, does it create a strong feedback loop too. Players want to continue playing to keep seeing those fireworks! My concept is simpler, but follows in that thinking.
After the user has clicked on 3 items (which by internet terms, three clicks is usually all you get in order for a user to make a judgement on a site), they are presented with a celebration button. They click it, and the button explodes with confetti, plays a nice sound effect, and then politely dismisses itself from the interface. This also provided a nice transition to remove the empty box that held the user’s text responses in a way that is initiated by user.
Oh boy, the problems. In my opinion, there’s a bunch, but let’s focus on the ones that cost me the most time.
One of the biggest issues was creating an environment that was easy to test on. To my dismay, it can still be tricky to accurately test on a real mobile phone (emulators just don’t do real mobile hardware justice) without pushing the site to a physical server online somewhere. This gets even trickier with WordPress’ database wanting to know the exact URL of the site, so storing it in a subfolder on a live server and then moving it requires extra steps as well to get all those links fixed.
My approach was to begin development locally with MAMP, with a duplicate test database (also local), and then when it was all finished, push the files up to the server and then point the config file to the live database (which had roughly the same content). However, as I began adding more content to my local database, it became clear that I would need to merge my existing live database with my local copy. Thankfully, WordPress makes this easy as you can export certain sections of your site with their XML exporter, and then import them back into a new WordPress site — anytime I can avoid manual SQL manipulation, I do. I’m just not that great at it yet.
Additionally, by using AJAX to pull in external HTML files that contained the bits and pieces of DOM needed for the website’s text responses, I needed to specify an exact domain in order for the append function to work correctly. This was tricky at first because pushing it to the live website meant I had to adjust the live JS file and make it different than my local JS file. Thankfully, James showed my how I could dynamically pull in the URL into the AJAX query based on the browser, and that allowed my to keep my local and live JS files the same.
Finally, I ran into some majorly dumb issues with getting scrolling to work properly. I won’t even go into scrolling issues that I’ve encountered with iOS, but let me just tell you that scrolling inside a fixed position div with overflow hidden does NOT ALWAYS work. It’s weird, but it will get glitched up… every time. In this particular case, I had issues with keeping the text bubbles anchored to the bottom of the text window div, and then also have that same div scroll down automatically when new responses came in. I had to settle for letting the bubbles stay at the top of the window at first, and then as the content became taller than the visible screen, JS jumps in and scrolls the screen down for you when the user clicks a response button. Initially I had a function checking to make sure the text window div was always scrolled down, but this removed the ability to scroll back up… which kinda sucks if your mobile phone screen is small (iPhone SE, anyone?) and you can’t get back to offscreen links.
In an earlier post, I had written that I felt like this new website was a great platform to expand on. And I still think that, although I don’t think just having an interactive homepage will suffice anymore.
I think the text-messaging piece will become more of one of the “intro pages” we used to see on the web way back when (although I believe mine is still much more functional), and the rest of the site, mainly my portfolio and blog posts, will need additional pages in order for users to effectively navigate through their contents.
Lastly, I feel like this website concept breaks the conventions so much with the initial homepage, that the other pages designs can as well… in a way. If all the main pages of the website looked different (typically a very bad approach), would the user feel that there was cohesion in that they could expect them all to be different on purpose? I have no idea. Steve Jobs would of said that if he felt it was best for the user, than it was. Every other company in the world would probably do focus/testing groups with users. Me? Maybe a mix of the two, but more than likely just asking friends for feedback instead, and paying them with high-fives and maybe pizza.
While I was sincere in my initial writing of this post… well, the design didn’t have a whole lot of room for experimentation as I had originally hoped. While the website succeeded in it’s concept of getting people involved and clicking, it didn’t really facilitate the primary need of my website being a repository for my thoughts/work… you know, a blog. So, here’s to reworking the design… again