Submission 2

Initial Planning, Conception and Justification of Decisions

We began our second submission with the mark from submission one clearly in our memories. Due to the fact that feedback stated “the deepest understanding…can only really come from experimenting with code,” we made sure our second submission was code intensive.

We decided that the best way to show device specific nature of responsive design would be a device-specific interactive game. We envisioned a puzzle-like riddle that allows a community of mobile gadgets to solve it. We wanted to create a non-linear set of problems that could only be solved from start to finish with a multitude of devices.

We met and developed a plan for the project. We decided that 6 different media queries/device ranges would be optimal, due to the fact that users’ attention and ability may vary. We aimed to keep them interested.


The Design Process including Early User Testing

From the beginning, a six-block web page structure was developed. Each block represents a different media queries’ range of devices based on the device-height or device-width property.

We began with a list of potential devices ranges in which to focus. We chose some of the most readily available and most used devices on the market. Various iOS and Android devices and common laptop and desktop sizes were used to allow for the highest number of participants.

From here, each group member chose a particular device range for riddle development. Due to our specific ranges and potential devices, specific riddles and mini games were developed using CSS and JavaScript. Each of us were required to research the individual capabilities.

A very simple example would be: large image-based riddles would not be used as riddles on smaller screened devices & and touch-based games would not be developed for a laptop.

From there, the page was developed in block form. Six blocks were created on top of each other via HTML/CSS. Each block was connected to a media query with a specific range of device sizes.

When a device from a specific range opens our website (located at, a specific block and riddle is displayed. Upon successful completion of the riddle by entering the team number, answer and clicking ‘submit’, the user continues on to another device until all six riddles have been completed.


The presentation of the project was an event open to all students and friends to join a friendly ‘Riddle Hunt’. As it took place just after Easter we decided to give out chocolate Easter eggs to the first ten successful hunters. People that joined the event could participate as a group or individuals, and sharing their devices was something we were hoping for, as we initially thought that this hunt could be used in a social manner of bringing people together. People that came to the launch were very enthusiastic and happy to participate, and their encouragement was enhanced by the chocolate threats as rewards. While playing students from different majors worked in groups or exchanged answers and hints with other participants, which we thought of as a great success.

Since only the first ten participants were rewarded, we decided to place a results page on a big screen that would automatically update the current position of each player/s. This also served as a way for the ‘hunters’ to see if they have answered correctly a question and how many they have left till the hunt is over and they can claim their reward. This brought up the competitive side of the game when players could see not only their own progress, but also the one of other participants. While launching ‘Riddle Hunt’ and looking at the results page in action we discovered an interesting component of the game, which we haven’t thought of before. While participants would need to enter the same team name each time they answered a question in order for the system to recognize them and add their correct answers, they could also quickly change the answer of a particular question of another participant, in order to surpass them and be successful. We thought that is a great way to bring out the competitiveness in players and decided not to change the results system after the initial presentation.

Overall we consider the presentation as a successful one, with more that 4 participants winning a price and indicating that they have enjoyed themselves. Players not only played a game as individuals, but they also socialized between teams, and at the end even shared the rewards they won.

Post-presentation work

After the presentation we had an immediate meeting as group to discuss its outcomes, reflect on the responses we had and the technology issues we’ve encountered during the launch.

We decided to adjust and fix some of the problem that participants in the presentation brought to our attention.

The work was divided as follows:

One of our biggest focus points was the results page. Although the alpha form that was projected on a screen during the presentation was designed to match the Easter theme of the rewards, it proved to be less efficient in effectively showing to participant their progress. Therefore we decided that it needed to be the first improvement and change the way that players view their answers (a correct answer lights up in green, rather than the incorrect’s red). Another problem was that the results page design was not linked to that of the ‘Riddle Hunt’ posters, flyers and overall was lacking as part of the brand. By the time of the second submission the entire mentioned problem was fixed, and design was adjusted to the one of the posters.

While presenting the game we discovered that after an answer is submitted the answer box isn’t cleared, which could give an opportunity for players sharing devices to use one another’s answers. The beta submission of the web page would have the problem fixed, alongside with two of the riddles, which proved to be difficult for the players and/or being presented in an unclear manner.

Testing Procedures and Outcomes

There have been multiple iterations of our project due to development issues with our code. Procedurally, each time our code was changed we tested the functionality on as many applicable devices as possible. Our initial outcome was a lack of exclusions on our media query leading to the entirety of our blocks being displayed on devices outside of our queries.

We remedied this by a more comprehensive approach of restructuring our media queries. Making sure that our device ranges were listed in ascending order and that there were no gaps between devices was the key to our further development. By the time of our presentation, much of our desired functionality was working. Feedback was taken and used to do some major revisions to our project.


Clear Description of Who Did What


  • Initial concept including general design and structuring
  • Individual riddle creation and coding
  • Code troubleshooting (with Amy’s assistance)
  • Group organization
  • Group assessment outline


  • Individual riddle creation and coding
  • Recording of the presentation
  • Writing of the second submission group write-up
  • Role as a presenter and guide to participants during the presentation


  • Individual riddle creation
  • Design and coding of the entire alpha page and fitting together the individual riddles and media queries
  • Post-presentation adjust of the main page to refresh and clean answers after submission
  • Code troubleshooting


  • Individual riddle creation and coding
  • Group organization
  • Revision and help with coding during the alpha stage
  • Post-presentation improvement of the ‘Spot the difference’ riddle
  • Purchase and move of  the page to a unique .com domain


  • Individual riddle creation
  • Organization of the presentation event – rewards
  • Group organization
  • Creating of custom flyers and posters for the presentation events
  • Post-presentation adjustment and coding of the results page to show colours according to correctness of answers


  • Individual riddle creation
  • Creation and coding of the alpha results page
  • Post-presentation further development of the results page
  • Organization of the presentation event – awards
  • Printing posters and decoration of Atrium on the presentation day


Additional photos from the presentation


Cooperation vs. Competition

Cooperation is a tenet of our society. It is the underpinning of civilization and the difference between the modern world and antiquity. Grouping of individuals holds cultures together. It is this instinct that enables the populous to thrive, keep food on the table and survive. It is human nature. We want to be on a team.

Conversely, human kind is also fiercely competitive. A basic desire to be the best – and a need for the less capable or skilled individuals to fail is even present subliminally; natural selection is a striking example. It is also human nature. We want to win.

It is the point of intersection between these two evolutionary necessities that I find most interesting.

I believe the best way to highlight these traits is through a cooperative game or puzzle. It is this idea that served as the platform for the responsive web design project.

A combination of human nature and digital technology enabled the development of a skills-based game that showcased the power of media queries’ device-specific content and cooperative-competition (if such a thing exists).

From the very beginning, the development hinged on the fact that most, if not all, of the users would not own every device needed to complete the puzzle from start to finish. The observation of how a game requiring the use of multiple devices was played by a group of participants was an experiment not only in technology, but also of psychology.

It was difficult to predict how participants would behave prior to the game.

In an article from the Quarterly Journal of Economics in 1999 discusses the balance between cooperation and competition in not just an economic sense.

“Some pieces of evidence suggest that many people are driven by fairness considerations, other pieces indicate that virtually all people behave as if completely selfish, and still other types of evidence suggest that cooperation motives are crucial.” (Fehr, E. & Schmidt, K. The Quarterly Journal of Economics (1999) 114 (3): 818.)

This statement rang true was in our project, as some participants chose to compete, others to cheat, some to cooperate and many chose to be fair and share. The amount of competition was especially interesting to note, given the fact that the only prize winnings were chocolate eggs.

Since the point was to complete the game in the shortest time possible, participants hurriedly solved the first puzzle. This is when it got interesting. The first puzzle completed by most people was on an iPhone or iPad; two devices that many brought with them.

This meant that sharing was not required. There was a competitive, urgent rush onward – until it was made clear that the use of some uncommon devices was also needed. Some groups were unaware that a communal effort was required while still maintaining the rivalry of individuals. This provided a point of contention for some players. If devices were shared – others would have the ability to catch up. If they weren’t shared – others would be stuck, but there would be the very distinct possibility that no one would be able to complete the entire game.

In addition, devices were snatched and teams ran off to complete a particular puzzle away from the rest of the participants (as to prevent overhearing the correct answer). This tactic was quickly derailed when it was discovered that some devices did not clear the answers after the ‘submit’ button was pressed; thus leaving a hint (or sometimes more) for the next group to use the device. Frustration was a common denominator for many.

An aspect of the sharing/competition quandary found in this experimental project that was not anticipated was the prevalence of cheating (or ‘alternative completion methods’ – for lack of a better term). Some players late in the evening found that the Opera browser’s device emulator allowed for a one-device solution for most of the puzzles. Through desktop-based emulation of many of the devices used for the game, the need for sharing was removed altogether. This was not only a quick way to solve the puzzles, but a sly one – and not something that was thought to be a problem during the development stage of the project. The Opera emulator’s functionality on our site has since been removed.

Another important point of contention for many players has to do with score security. Solutions to puzzles are entered through ‘team name’ and ‘solution’ input boxes. The ‘team name/number’, if entered exactly the same way on every puzzle, shows up on the results page as a single entry with each puzzle completed, an indication of the correct or incorrect answer and the time elapsed. It was quickly determined that any team on any device could re-enter a name/number with an incorrect answer to remove a previous team’s correct answer. This form of sabotage was quietly executed throughout the game and resulted in some upset teams. Also, if a team did not pay attention to exactly how their name/number were entered in the input field, a duplicate entry was created on the results page and a new timer was started.

Overall, the human interaction with our project showed that a fine line between competition and cooperation exists. People tended to not share unless absolutely necessary and many will go to great lengths to win, even if that includes bending the rules. I, for one, did not think that a small group’s studio project would allow for such a psychological observation or elicit such a competitive response from participants.


By 18 April 00:00 GMT

1. Empty answer box when page is refreshed – Serena

2. Re-style results page (make pretty, colour indication) – Findo, Ming

3. Improve riddles
-Spot the Difference – Will and Jacky
-Words/Letters (Better instructions) – Findo

4. Write Up
-Until Now – Will (+Serena for Code)
-Finish – Christin

Project Overview

Our group was determined to use responsive techniques and media queries to produce an entertaining, engaging project. The Alpha Submission showcased our understanding of the techniques involved – but lacked an outside of the box approach. We decided to create a riddle-based problem-solving project that requires media queries and device-specific problem solving to complete a riddle. This system allows users to connect mind and device together; through a plethora of devices and the use of logic. Our project provides an understanding of the differing device specific code that is used around the web and how content is displayed differently of various devices.

Our concept was first defined during a brainstorming meeting. We knew that an interactive presentation would be best – as it would involve members of our group, our program, and the public. We find that responsive and device-specific design and web pages are best understood through first-hand usage.

We began with a chalkboard sketch of the general format for the page. A decision was made that through the use of a beginning riddle – users will make their way to the end of the task by coming up with solutions for puzzles that lead from one device to another. Through this inter-device navigation – only some devices will display particular steps in the task. Therefore, users will find out the similarities and differences between browser types, screen resolutions and what particular technologies are displayed by individual devices.

For instance, a clue within the riddle may be viewable on an iOS device, but only those with a screen resolution less than an iPad Mini. These devices include the iPhone 5, 4S, 4 and 3GS. A different clue may be accounted for by the use of a full-size iPad, for instance. Some clues may only be visible on Android tablets – as many of them share screen resolution. In addition, some clues may be found through the use of browsers that support webkit, but not through others. A sample resolution chart was constructed.

Since many devices share resolutions and browser capabilities, there will be some overlap on devices that display the clues. One common denominator in the entire puzzle is the database integration that will require users to enter the correct answer to the riddle in order to move on. A running scoreboard will be on display during the puzzle to see which groups are in the lead.

We hope that this project will aid in the understanding of media queries, how they are constructed, and how different content may appear on different screens – or perhaps not at all. This project has been very much a group effort. Each of us took on our own task, or two – and many aspects of the project including coding were undertaken by us all individually and combined for the final site.

The Wild World of Responsive Media

The Wild World of Responsive Media
By Will Thomas

Content is the key to any website. Without meaningful, reliable and easy-to-access content, a website is just a collection of shapes and colors. Great for an art project – not so great as a resource. But content doesn’t just revolve around text. Font choice, size and color make a huge difference on a user’s experience with the written word; but a key to the overall takeaway value from a website comes from the right combination of text and media.

Users of the web aren’t what they were a decade ago, or even 5 years ago. The proliferation of fast, inexpensive wireless networks; mobile devices with immense computing power; and the overwhelming demand for tablets have forced the web to change venues. Or, at least, get a little bit more flexible with how it is formatted.

Gone are the days of the Yahoo Geocities-styled, flashing colors, morphing cursor, marching ants and terrible gradient background single page website. Today’s web is [predominantly] clean, clear and accessible on a variety of devices. This is where the term responsive comes in.

A responsive website, at its most basic, is a site in which the aspects of content, layout and navigation remain similar, yet vary depending on the viewing platform.

EXAMPLE w/ Screenshot: uses responsive techniques to tailor its content to display well on different devices.

More than just creative reordering of text boxes and font sizing go into a properly responsive site. Since the content is more than just textual, images, videos and even ads must be taken into account.

Dynamic Fonts

To begin understanding scalability of content, however, the most fundamental place to begin is with the text itself. For a news website, making sure that a user can read the written word the journalists have crafted is important, whether it is on a desktop computer at home, a laptop at work, or a mobile phone or tablet in between.

Font sizing on the web has two major groups: Static and “Dynamic”. Static sizing is exactly as it sounds; no matter what, a static unit remains the same regardless of the viewing platform. Some common examples of static font units are pixels (px) and points (pt). They both operate similarly and representation a fixed size. For instance, a font size of “12px” will display as twelve pixels on every screen. In a perfect world, where devices are standardized and twelve pixels display the same way on every screen this is not a problem. That perfect world doesn’t exist.

It comes down to the fact that different screens have different pixel densities, meaning one screen with given dimensions may have more pixels per inch than another screen with the same dimensions.

EXAMPLE w/ Graphic: Over time, Apple has similar screen dimensions on its iPad models, but with varied pixel densities. Early iPad models had a resolution of 1024×768 pixels @132 Pixels Per Inch (PPI). Later models with the same size screen have a resolution of 2048×1536 pixels @ 264 PPI. The new iPad Mini uses a screen of smaller dimension with the same resolution as the early larger models, but with an intermediate pixel density of 163 PPI.

It’s easy to see how a font displaying at twelve pixels (or similarly with points) would display differently depending on particular iPad model. Given this restriction, developing a website with static font units is a death knell. Thanks to the constant advancement of web technologies, there are solutions to this issue.

The easiest way to go about minimizing cross-platform/cross-device issues relating to font size is to use one of two units: Percent (%) or Ems (em).

These units rely on the relationship between at least one other fixed sizing somewhere else on the page. An initial font size (let’s say 12px) may be set for the large-format version of a page, perhaps in the body class of a CSS style sheet. By doing so, the base unit (em or percent) is set to twelve pixels. Larger text can then be coded as anything larger than 1em (using decimals) or 100% (using percentages). Smaller text can be coded similarly.

For example, the body text set at 12px could be coded as 1em or 100%. Headings could then be coded as 1.5em or 150%, depending on what works for the page.

EXAMPLE: body { font-size: 12px}…h1 {font-size: 1.5em}…OR…h1 { font-size: 150%}

The flexibility of this kind of coding allows for different style sheets or different media queries to simply change the initial font sizing for the page (ie. the body { font-size: __px } tag) and the relationship between the rest of the text on the page will remain the same. Headings will still be roughly the same size difference from body text, etc.

It must be noted, however, that pixels are not the only units that can be used in as the basis by which the other units are related. All the units have a rough equivalent, 1em = 12pt = 16px = 100%. Many designers will set the body font size as a percent and use ems to scale from there.

Other options exist, such a JavaScript libraries and other such plugins, but none are as simple as using dynamic units.

In addition to font sizing, it is important to consider the font face used to display the content. The use of various devices with different fonts installed adds to the difficultly of uniform display of text. One way around this issue is through the use of embedded fonts. Using the @font-face CSS code, or an online font library like Google Web Fonts adds a bit of load time to a page but reaps many benefits of cross-device display conformity.

Dynamic Images

In the world of the responsive web, images are one of the biggest pains when it comes to sizing. How does a designer maintain the use of a text-content-related image on a page that may be viewed on a hundred different devices with varying screen sizes and resolutions?

Well, the first and easiest test is to make sure that the image is important and adds meaning to the content no matter what device displays it. Once that first test is passed, it is important to make sure that that image is of a widely compatible format, such as JPEG or PNG. If the image is still deemed worthy of display, chances are it will find itself living in a DIV. An easy way to keep images behaving nicely with their parent DIVs is to utilize CSS’s “max-width” function. Using “max-width”, an image with a dimension of 800×600 pixels is only allowed to display at its full size if the DIV in which it is contained is large enough.

This method is especially handy when DIV dimensions are coded using percentages of a given screen. Simply put, if the desktop version of a site has a container DIV with a width of 960 pixels, the 800×600 pixel image will display at its full size. If that page is designed to scale when the window is smaller, lets say 500 pixels in width, the entire image will still load inside the DIV instead of getting cropped; it will simply display at a smaller dimension.

This is the simplest way to make sure images remain responsive, but it does not account of every issue. For instance, a mobile device using a 3G connection does not load image-intensive pages as quickly as most wired or WiFi connected desktops. It may be important to consider loading a smaller resolution (and therefore smaller file size) image when a page is viewed on a mobile device.

A good way to get around this problem is through the use of the “adaptive-images.php” script. It uses a modified .htaccess file to force web browsers looking for images to load to use the supplied .php function instead. It finds the appropriately sized image from the server and displays it. The best part is it doesn’t require you to re-code any of your existing HTML/CSS. Using PHP and a bit of JavaScript, Adaptive Images uses the original high-resolution image and creates/links to smaller versions by itself. This is a modification of Filament Group’s content-aware image function, but is a bit more straightforward and simpler to implement. The major drawback is that you need PHP running on your server. It also won’t work with content delivery networks. A ColdFusion version of Adaptive Images is also existence, but if you’re still using CF you’ve found your first problem.

Dynamic Video

In many ways, it makes sense to think that scaling a video player in a responsive website would work in much the same manner as an image. This is both true and false. True HTML5 video will indeed scale like an image, using the appropriate HTML or CSS code.

EXAMPLE: HTML – OR CSS – video { width: 100% !important; height: auto !important;}

That is great if you are using HTML5 video. Not only will it display in most modern browsers and on most computing platforms and mobile devices, but it will also scale like an image. The issue rears its ugly head when you start dealing with video hosted by YouTube or Vimeo using an iframe.

That’s where jQuery comes in. It allows you to remember the aspect ratios of the videos that are loaded on a page and when it is rescaled, the videos are scaled accordingly to fit the given width of the parent element.

If you have the ability and bandwidth to host HTML5 compliant video on your server, do it. If not, the JavaScript solution will work, even if it is a little clunky.

All in all, responsiveness is crucial in any site that is intended for widespread use. Any site that is worth using is going to have some kind of multimedia as part of its content. Such content isn’t outrageously difficult to set up correctly and will provide a much more rewarding user experience.

January 30

Good meeting today, all!

Absent: Christin (Sick)

  • Mobile-first development is key. Start with the simplest, most basic mobile version and build on it with media queries.
  • Some mobile devices do not understand media queries, so making the mobile version the first code that displays.
  • CSS hierarchy is important.
  • Use classes, not IDs.

Some responsive sites:

For next week:

A draft of a .NET magazine-style article for our first submission.

  • Will: Responsive Media (Media Queries included.)
  • Findo: Responsive vs. Mobile Sites (Focus on BBC)
  • Serena: User Experience (Focus on Human Interface: Touch, etc.)
  • Jacky: Accessibility
  • Ming: Responsive Layout (Fluid Grids)
  • Christin: Pro Tips on HTML5 and CSS3/4, What’s Good/Bad/Works/Doesn’t Work. Pick 3-6 keys and elaborate. (, etc.)

Remember, the key is that pages scale UP to desktop, not DOWN to mobile.

Simple isn’t so simple.

I started into building a “simple” responsive website and quickly discovered that such a thing doesn’t exist. The whole premise is straightforward, but the end product is never without complication. There are about 50 ways to do everything. Adaptive font sizes? Using em units works, but only on initial loads or page refreshes. JavaScript? Again, that works. But it’s clunky.

I tried to focus on essence of an adaptive website. The reason is exists in the first place. People access sites from many different devices, on different platforms, and with differing screen resolutions and pixel densities. With all of these things considered, what is the most important part of a website? Displaying the content in a way that makes the user able to navigate it and comprehend it.

So I just created a basic layout-swapping and adaptive-sizing page using a placeholder image and some dummy text. It’s not extravagant, nor is it beautiful; but it shows how media queries work and the basic principle behind adaptive sites.

If this was an elaborate, complete design, I would have used em units for everything because px units don’t convert directly on screens with various pixel densities.