The basic premise of responsive design is the concept that webpages adapt to and adjust their layout (and sometimes content) for the viewport. The three original tenents of Responsive design from A List Apart article by Ethan Marcotte (2010).
Fluid grids (usually 12 columns)
Flexible images
Media queries (bits of CSS code that told the browser when to change parts of the layout and what to change it to)
I was just starting out on the web when this new paradigm shift happened. Before you had to design for a 960px grid system for screens that were 1024px wide. Everything was pixel-perfect and exactly like the comps supplied by designers from a Photoshop file. When responsive design became a mainstay due to the proliferation of smartphones it was a game changer, as in theory, you had to think of a myriad of layouts (in practice it's usually three, desktop, tablet, and mobile). I also remember about this time the mantra was "mobile first", where you thought of the layout for the mobile-first and built up the design and the coding as progressive enhancements. However, from my experience, the designer I worked with at creative agencies in the past all used huge Macs which had tons of screen real estate and may have contributed to biases. When the comps came to my desk, they were ALWAYS desktop designs and we would have to discuss (almost every time) the mobile layout. This was often because the clients were B2B and expected to see the desktop site they had paid for when reviewing design changes. In some respects, this was great for me as I was able to problem-solve the issue, and gave me some additional fulfillment in my front-end role, but I was not a trained UX designer and had to rely on my best judgment, rather than user's needs.
Task 1: Redesign on a Grid
[~30 minutes]
Take one of the wireframes you made for your UX Prototype. Duplicate the design file (or just the page, or artboard) and redesign it on a grid.
Have a think about the following:
What was that process like for you?
What changed?
What are your impressions of the before and after?
This is one I had already done during my wireframing, which has more to do with my fastidious nature when designing with digital tools than anything else. I feel I have less inclination to do this when I do initial designs as paper prototypes and that is probably why I prefer them initially to wireframes ( I missed using paper prototypes, I prefer them over sketches as well as I can swap out elements quickly but not be tempted to get bogged down with grids or alignments). This propensity hasn't helped my productivity and is another contributing factor to why I'm so behind. For this challenge, however, it worked to my advantage. (figure 1)
I decided to look at the layout for the "Add Skills" page, I've used a 12-column layout for the general widths - using a column on either side for spacing. I found this gave the content the space it needed as the gutters on either side were too small and the design look too butted up to the edges. I also used a 5-column layout for the main navigation at the bottom, as 12 isn't divisible by 5 and I had 5 elements to space. The top tabs use three columns, the tabs span 4 columns each on a 12-column layout.
So why did I use a 12-column layout on such a small screen? The answer is that's what I'm familiar with. As a web developer, I've used Bootstrap and Foundation extensively in the past, and these all use a flexible 12-column system, even on smaller viewports (although the content will often span all 12 columns on most of the content at smaller viewports, giving the appearance of a "single-column" layout).
Takeaways
On the one hand, my conceptual model using bootstraps/foundations restrictions meant that I was able to understand the concept straight away, but it also restricted me to a set pattern. There are two issues with this approach:
I ALWAYS seem to stick to a column-based grid system, which restricts my design choices, particularly when there are opportunities to break convention and add some tension to the design. I don't seem to want to break the rules!
I start off the initial wireframes with the grid in mind and try to stick to it from the beginning. As I said before this is slowing my workflow down. It might be too late to make changes now on the way I approach the wireframes, but moving forward I need to just get the screens out for testing. Although this is by no means the only reason for my "bottleneck" in the production, it's definitely not helping.
Task 2: Wireframe a Responsive Layout
[~60 minutes]
Select one of your screens from your UX Prototype. Either on paper or in your design tool, rearrange the elements to fit a medium screen size (tablet, eight columns) and a small screen size (mobile, four columns, or one).
Did you make any changes in hierarchy? Sizes of elements etc?
I decided to mix up the challenge this week and reverse it. I think the intent from looking at the weekly content was that the artefact was a website on a large viewport and to scale down. However my concept was an app, so I’d be scaling up to a design with a breakpoint above 960px. I decided to stick with the bootstrap style 12-columns mentioned earlier. I’m also going to keep in mind something called Flexbox, which is a CSS technique that allows you to reorganise your content regardless of the markup. I find it's great to reprioritise content if the use case means priorities change on different screen sizes. This happened once at work, where a design decision was made to show the prices for our products on the top of the desktop so we could ensure it was above the fold but it made more hierarchical sense for it to be next to the call to action on mobile. This was based on metrics we had at the time and using Flexbox we were able to achieve this. Flexbox Froggy (n.d) was also an invaluable resource at the time for this at the time and really help understand the core concepts.
I decided to use the Layout shifter approach for the challenge mentioned in this week's content (Brown, 2021) as I felt elements for the header section in particular would work better in a slightly different order and I wanted to put the hero image at the top. In some instances, I found the additional screen space an opportunity to deliver enhancements. The search, for example, could be initiated quicker by now having it nested in the navigation, as I felt this could be added without the page being too overwhelming and busy.
Reformatting the page like this definitely made me think a bit more about my approach to the artefact. I had decided to produce a mobile app because of the convenience for the persona, reducing the barrier to volunteering, and I hadn’t really contemplated designing a website. As a web developer, I’m used to seeing web layouts and how responsive design works, but up to this point, I clearly hadn’t engaged this part of my professional experience designing the artefact. Although some of the design elements were easy to convert into their counterparts such as the navigation and headings, I felt the rest of the content lacked a defined hierarchy when played out this way. Perhaps if I had been aiming for a responsive design from the beginning I would have thought more about which element should go where on a reshuffle to better convey the user's story. My initial intent was to have the user see where they’ve been (the projects they’d used the skill on, and the people who endorse the skills) and where they can go next (the skills they could learn, and where they could find new opportunities). When this was reshuffled into a larger screen though the elements seemed to compete with one another, especially the Endorsers and the volunteering opportunity which now sat on the same level horizontally and spoiled the “story” metaphor I was going for. I could have simply nudged it down and had the endorser on a single row, but this would have negated the benefits of more screen real estate and I was also conscious of what that section might look like if there were only one or two endorsers, leaving a large gap. Either choice presented a challenge because vertically this could also be true. The content and volunteer opportunities could be tall and this would mean gaps for endorsers as well. (Fig 3)
Takeaways
I’m ok to call this one a swing and a miss. My initial intent was not to create a web page or web application but a native app where space is at a premium so the design considerations were different. That being said, 47.75% of website visits between March 2022 and March 2023 in the UK are on a mobile device and 47.15% on desktop (statcounter.com, 2023), so any web project is going to need to take both into consideration. As stated before, I’m used to helping design teams translated their desktop designs into mobile versions, but I found it tricker doing it the other way around. Next time I’ll take it into consideration.
Task 3: Review Your Design for Accessibility
[~30 minutes]
Review what you have designed for your project.
What might you change to be more accessible to users?
How might you implement that?
If you have thought of a colour scheme, how would it stand up to accessibility if it was applied to your project?
I decided to use the Figma plugin Stark to see if my design passes the WSAG 2.0 guidelines and receives a AA rating.
It started out so well, with the pale blue background working well with the dark colour of the copy I had chosen (figure 6), however, some of the smaller items use a more muted and subtle colour pallet, based on tints and shades from the colour combinations I chose in week 8. These did not perform as nearly as well and failed to gain the AA rating (figure 7).
I will need to reevaluate the colors I use for the project again, after agonizing on each to ensure each conveys some meaning, but that is pointless if they aren't usable. The contrast is simply not there to achieve a double AA rating. I don't want this to be an afterthought as well, as I made it a priority to ensure all touch targets conformed to the 44px rule by the WSAG 2.0 (w3.org, n.d.), so I don't want to undo the gains I have made there.
Project update
I feel like I'm very close to having something testable for users to finally try out this week. I have a list of testable elements, and I'll try to keep an open mind. It's been difficult to balance because I've been trying to keep up with the weekly challenges while also being aware of the need to test. It's causing me some seriously anxious moments, as I just can't seem to get the functionality right. For my final prototype, I think I'm going to have to use Protopie. At least with Protopie, you can create a more sophisticated state (i.e., you can delete elements and add them and it persists). Also, drag and drop is very clunky in Figma as it's based on smart animate between two frames. Dragging in any direction will trigger the animation. If I were using JavaScript, I would definitely leverage a framework like Sortable (n.d), but I'm not seeing a plugin that can do that in Figma. So maybe it's time to jump ship? I'm only concerned with the time it would take to learn Protopie, but I'm really struggling to get the functionality to work without creating dozens of screens. And every time I change something, I have to change all the screens because they're supposed to be the same screen. (figure 9.)
It also stopped me from styling all the screens as I'd have to swap out the design for dozens of screens and make sure they were all us to date. And this is only one piece of functionality. I wanted to test an idea I had for endorsing users, but I think that going to have to wait. I feel like I'm in a real bind, there's got to be a better way of doing this! I might see if any of my cohorts have any suggestions because I'm drowning in it at the moment and feeling overwhelmed.
References
BROWN, Clementine. 2021a. ‘Week 8:Responsive Design.’ Canvas Falmouth
University [online]. Available at: https://learn.falmouth.ac.uk/courses/283/pages/week-9-responsive-design [accessed 19/03/23].
StatCounter. nd. 'Desktop vs mobile vs tablet market share united kingdom' . StatCounter Global Stats [online]. Available at: https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/united-kingdom [accessed 19/03/23].
Flexbox Froggy . n.d . A game for learning CSS flexbox [online]. Available at: https://flexboxfroggy.com/ [accessed 19/03/23].
MARCOTTE, Ethan. 2010 Responsive Web Design, A List Apart.[online] Available at: https://alistapart.com/article/responsive-web-design/ [accessed 19/03/23].
SortableJS. n.d. Sortable: a JavaScript library for reorderable drag-and-drop lists. GitHub. Available at: https://github.com/SortableJS/Sortable [accessed 20/03/23].
Understanding SC 2.5.5:target size (level AAA) n.d. Understanding Success Criterion 2.5.5: Target Size | WAI | W3C [online]. Available at: https://www.w3.org/WAI/WCAG21/Understanding/target-size.html [accessed 20/03/23].
Figures
Figure 1: CLARKE, Daniel. 2023. Column alignment on the wireframes
Figure 2: Blue Bay Travel. 2023. Desktop formatting showing Price at the top. From: http://bluebaytravel.co.uk
Figure 3: Blue Bay Travel. 2023. Mobile formatting showing Price above CTA. From: http://bluebaytravel.co.uk
Figure 4: CLARKE, Daniel. 2023. Mobile app reformatted as a desktop website.
Figure 5: CLARKE, Daniel. 2023. Vertical Gap issue on desktop with the endorsement section
Figure 6: CLARKE, Daniel. 2023. The Stark plugin for Figma showing a AA rating on the background and text
Figure 7: CLARKE, Daniel. 2023. The Stark plugin for Figma showing failed result for the rating pill in the skills cards
Figure 8: CLARKE, Daniel. 2023. 13 screens for 2 pieces of functionality on the Skills HQ section
Comments