Listen, I am no GraphQL expert but I do enjoy working with it. The way it exposes data to me as a front-end developer is pretty cool. It’s like a menu of available data and I can ask for whatever I want. That’s a massive improvement over REST and highly empowering for me as a front-end developer who desires to craft components with whatever data I think is best for a UI without having to make slew of calls for data or ask a back-end developer to help make me a new bespoke API for my new needs.
But… who builds that menu of data? Somebody does.
If that somebody is a person or team at your own company because you’ve built out your own GraphQL API for your own needs, that’s great. Now you’ve got control over what goes in there (and when and how).
But sometimes GraphQL APIs are just handed to you. Perhaps that is how your CMS delivers its data. Still cool and useful, but that control is at the mercy of the CMS. You still have a menu of options, but the menu just is what it is. No substitutes, to continue the metaphor. If the menu doesn’t have what you need, you can’t go back into the kitchen and add extra sauerkraut to that reuben or have the steak fries come with fried mushrooms.
This came up in a discussion with Simen Skogsrud and Knut Melvær on an episode of ShopTalk. Their product, Sanity, is like cloud storage for JSON data, and a CMS if you need it. A modern product like this, you’d think a GraphQL API would be a no-brainer, and indeed, they have a beta for it.
But instead of GraphQL being the main first-class citizen way of querying for and mutating data, they have their own special language: GROQ. At first glance, I’m like: eeeeeesh, there’s a way to shoot yourself in the foot. Invent some special language that people have to learn that’s unique to your product instead of the emerging industry standard.
But Simen and Knut made a good point about some of the limitations of GraphQL in the context of a third-party handing you an API: you get what you get. Say a GraphQL API offers a way to retrieve authors. A generic API for that is probably designed something like this:
But what I actually want is just how many authors we have on the site. Perhaps I wish I could do this:
{
allAuthors {
count
}
}
But that’s not in the API I was given. Well, too bad. I guess I’ll have to request all the authors and count them myself. I might not control the API.
This means that something like a CMS that offers a GraphQL endpoint needs to make a choice. They are either very strict and you just get-what-you-get. Or, they offer not only a GraphQL API but a way to control and augment what goes into that API.
In Santiy’s case, rather than offer the later, they offer GROQ, which is a query language that is powerful enough you can get whatever you want out of the (JSON) data. And rather than making it this proprietary Sanity-only thing, they’ve open sourced it.
With GROQ, I don’t need any permission or alterations to the API to ask how many authors there are. I’d do something like…
{ "totalAuthors": count(*[* in authors]) }
(I actually have no idea if the above code is accurate, and of course, it depends on the JSON it is querying, but it’s just conceptual anyway.)
By giving someone a query language that is capable of selecting any possible data in the data store, it has a big benefit:
You can query for literally anything
You don’t need a middle layer of configuration
But it comes at a cost:
Complexity of syntax
No middle layer means less opportunity for connecting multiple APIs, exposing only certain data based on permissions, etc.
You’ve created a Progressive Web App (PWA), designed an icon to represent it, and now you’re installing it to your Android home screen.
But, if you have a recent Android phone, your icons will show up like this:
What happened? Well, Android Oreo introduced adaptive icons, a new icon format that enforces the same shape for all icons on the home screen. Icons that don’t follow the new format are given a white background.
However, there is a new web feature called maskable icons that is coming soon to Firefox Preview and other web browsers. This new icon format will let your PWAs have their own adaptive icons on Android.
I work at Mozilla and have implemented support for maskable icons in Firefox Preview. I’ll show you how to add them to your own PWAs for Android.
What are maskable and adaptive icons?
Until a few years ago, Android app icons were freeform and could be any shape. This meant that web apps could also reuse the same transparent icon when pinned to the home screen.
However, manufacturers, like Samsung, wanted to make all icons on a device the same shape to keep things consistent. Some manufacturers even wanted different shapes. To deal with the variety of requirements from manufacturers and devices, Android introduced “adaptive icons.” You supply an image with extra space around the edges, and Android will crop it to the correct shape.
But web apps are designed to work on any platform, so they don’t have APIs to create these special Android icons. Instead, icons would get squished into white boxes like this:
Lo and behold, last September a brand new API descended upon us and was added to the W3C spec. Maskable icons allow web developers to specify a full-bleed icon that will be cropped. It’s platform agnostic, so Windows could use them for tiles or iOS could use them for icons.
How to create maskable icons
Since the maskable icon format is designed work with any platform, the size and ratios are different from the size and ratios of Android’s adaptive icons. This means you can’t reuse the same asset.
Maskable icons can be any size, and you can continue to use the same sizes that you’d use for normal transparent icons. But when designing the icon, ensure that important information is within a “safe zone” circle with a radius equal to 40% of the image’s size.
The safe zone
All pixels within this zone are guaranteed to be visible. Pixels outside the zone may be cropped off depending on the icon shape and the platform.
Warning: If you already have an Android app, avoid copying and pasting the icon from your Android app to your web app. The ratios are different, so your icons would look too small.
Adding the icon to your Web App Manifest
Once the icons are created, you can add an entry to your Web App Manifest similar to other icon assets. The Web App Manifest provides information about your web app in a JSON file, and includes an "icons" array.
Maskable icons use a special new key, "purpose", to indicate that they are meant to be used with icon masks. Icons with transparent backgrounds have a default "purpose" of "any", and icons can be used for multiple purposes by separating each option with a space.
"purpose": "maskable any"
Preview your icons
Do you want to see what your own maskable icons will look like? I’ve created a tool, Maskable.app, to help you evaluate how the icon appears in different shapes.
The app lets you preview your icon in various shapes that can be found on Android devices. I hope this tool helps you create unique icons for your Progressive Web Apps.
Once you’re satisfied with the results, you can start testing your app with Mozilla’s Reference Browser. This special browser is a testing ground for features before they reach Firefox Preview, and you can use it to check out how your PWA looks.
Tools like PWACompat also have support for maskable icons. You can automatically generate icons for iOS and other devices based on your new maskable icons!
Time to build your own icons
If you want to more control over how your PWA icons are displayed on Android, maskable icons is the way to go. With maskable icons you can customize how your icon is displayed from edge-to-edge. Hopefully this article can get you started on creating your first maskable icon.
The landing page for Apple Arcade has a cool effect where some “white” text has a sort of translucent effect. You can see some of the color of the background behind it through the text. It’s not like knockout text where you see the exact background. In this case, live video is playing underneath. It’s like if you were to blur the video and then show that blurry video through the letters.
Well, that’s exactly what’s happening.
Here’s a video so you can see it in action (even after they change that page or you are in a browser that doesn’t support the effect):
And hey, if you don’t like the effect, that’s cool. The rest of this is a technological exploration of how it was done — not a declaration of when and how you should use it.
There are two main properties here that have to work together perfectly to pull this off:
Next we’ll place text in that container, but we’ll actually hide it. It just needs to be there for accessibility. But we’ll end up sort of replacing the text by making a clip path out of the text. Yes indeed! We’ll use the SVG inside a element and then use that to clip the entire element that has backdrop-filter on it.
For some reason (that I think is a bug), Chrome renders that like this:
It’s failing to clip the element properly, even though it supposedly supports both of those properties. I tried using an @supports block, but that’s not helpful here. It looks like Apple’s site has a .no-backdrop-blur class on the element (Modernizr-style) that is set on Chrome to avoid using the effect at all. I just let my demo break. Maybe someday it’ll get that fixed.
It looks right in Safari:
And Firefox doesn’t support backdrop-filter at the moment, so the @supports block does its thing and gives you white text instead.
Whenever you hear of “mobile navigation”, what’s the first thing that comes to mind? My guess would be the hamburger slide-out menu. This design pattern had been in use since the first responsive design days, and even though a lot has changed since then, this particular pattern has not. Why is that?
How did we start using the top navigation with the hamburger menu in the first place? Is there a better alternative? In this article, I will try to explore these questions.
The History Of The Top Navigation And The Hamburger
The first hamburger menu icons started appearing in the ‘80s. It was designed by Norm Cox for the Xerox Star — the world’s first graphical user interface. He also designed the document icon for the same interface. This piece of history was uncovered by Geof Allday (who actually emailed Norm Cox). You can read the whole email response by clicking here. Later, it was seen on Windows 1 &
and DOS.
The current mobile navigation — as we know it — was popularized by Ethan Marcotte’s “Responsive Web Design” book back in 2011. Since then, the top navigation and the hamburger became the industry’s standard.
The Mobile Phone Screen Size Doubled In 10 Years
Since the original iPhone, mobile sales have been increasing year after year. 2019 is the first year that the market reached saturation point and the sales have started to decrease. But that doesn’t mean people are not using phones. By 2020, we will spend 80% of our time on the Internet on mobile phones, reports Quartz and Ciodive. Compare that to 2010, when only a fourth of Internet users were phone-based.
As phone sales increased, screen sizes have more than doubled, too. The average screen size of smartphones has increased from 3.2 inches all the way to 5.5 inches. In 2017, device makers started to adopt the taller 18:9 aspect ratio with 5.7-inch and 6-inch 18:9 displays. Now, we are starting to see 6-inch 18:9 displays become the new standard in flagships as well as in the mid-range price segments, as they have more screen area than 5.5-inch 16:9 displays, XDA-Developers reports.
Basically, the mobile phone screen size is getting bigger and bigger. That’s fine, but how do we adapt our design patterns to reflect these changes?
Thumb-Driven Design
I first heard of the term “thumb-driven design” from Vitaly Friedman. It’s based on the Steven Hoober‘s and Josh Clark‘s research on how people hold their devices.
The gist of it is that in nearly every case, three basic grips were most common. 49% held their phones with a one-handed grip, 36% cradled the phone in one hand and jabbed with the finger or thumb of the other, and the remaining 15% adopted the two-handed BlackBerry-prayer posture, tapping away with both thumbs, states Josh Clark. Steven Hoober had found that 75% of users touch the screen with only one thumb. Hence, the term thumb-driven design.
There are three main ways in which we hold our phones. (Large preview)
In 2016, Samantha Ingram wrote an article named “The Thumb Zone: Designing For Mobile Users” which further explores these ideas. She defined easy-to-reach, hard-to-reach and in-between areas.
However, I would argue, that with increasing phone sizes, the mapping has shifted a bit:
New thumb-zone mapping adjusted to larger screen sizes (Large preview)
When the phones were small, most areas were easy to reach. As our screens got bigger, the top part became virtually impossible to touch without adjusting your phone. From the example above, we can see where the most expensive screen real estate is. Yet, it’s often neglected on web pages. How can we fix this?
Bottom Navigation Pattern
Every now and then, bottom navigation pattern pops up on the web. The idea itself is quite simple: move the navigation bar further down.
Slack web page navigation reimagined with new thumb-zone mapping (Large preview)
Positioning the navigation bar at the bottom makes it easier for users to click on the menu icon, while secondary items can be moved to the top. Basically, you simply switch the order. Mobile apps have been using this logic with the tap bar pattern. It’s not a new idea in itself, but it’s still not as popular in web design as it is in app design.
This is not a foolproof solution since it raises a few critical questions, but it’s a worthy alternative. Let’s explore some of the questions that may come up.
Primary And Secondary Items
As the top of the screen is becoming hard to reach, placing the primary menu items closer to the bottom is a better alternative. But what about the other things that are just as important?
I propose two ideas to tackle this problem:
Placing the search bar or any non-primary items to the top;
CTA buttons should remain at the bottom next to the menu items as it is a vital part of the navigation.
A wireframe of reimagined primary and secondary navigation items (Large preview)
How Will This Affect Scrolling With Large Menus?
Some websites have extensive menus, submenus and everything in between. Naturally, there will be scrolling involved. How does flipping the primary/secondary items work in this scenario?
A wireframe of a reimagined large menu (Large preview)
Make the primary and secondary items (menu link, logo, search input) fixed while leaving the menu list scrollable. That way, your users will be able to reach the critical things they need.
Where Do You Place The Logo?
You might have concerns about the logo placement. There are two ways to go about it:
Placing the logo at the bottom might be a bit awkward, however, the thumb will most likely not obstruct it. It can be missed, though, as we tend to scan top to bottom.
A more reasonable option is to keep the logo at the top of the page, but not to have it fixed. Make it a part of the content so it goes away as you scroll. That way, people will still be able to see it perfectly.
A wireframe of the logo placed at the top while the menu can be found at the bottom. (Large preview)
How Does This Work With Handlebars?
Some operating systems and browsers tend to use the bottom area of the screen for their own purposes. iOS handlebars can get in the way of bottom navigation. Make sure the navigation is spacious enough to accommodate the iOS safe area.
If you place the logo dead in the center, the link might clash with the handlebar functionality. A bit of padding will do the trick.
Will The Users Adjust To This Pattern Or Find It Disorentating?
As I was writing this article, I kept thinking of whether this would turn out into a big redesign or a simple usability improvement for users navigating through your website. After all, according to Jakob’s Law, users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they’re already familiar with.
As a counter-argument to Jakob’s Law, I would like to propose Fitts Law. It argues that the time to acquire a target is a function of the distance and size of the target. Basically, the smaller and further away the target is, the higher the interaction cost. NN/g has a wonderful video explaining this in more detail:
“A bottom hamburger menu icon will have a much lower interaction cost compared to the top menu icon because it’s closer. By placing the menu CTA near the thumb, we are allowing the user to reach it’s end goal faster. Would the users find the feature disorientating if it lowers their interaction cost? Probably not.”
How Will This Integrate With The Tap Bar Pattern?
A tap bar patterns lists three to five most common first-level actions to click on a single row. You may have seen it in popular apps and some websites:
Hamburger menus have sparked a lot of controversy over the years. Just take a few moments to read this article, and this one, and this one, and most importantly, this one. You’ll then understand why the tap bar became the preferred navigation pattern in mobile app design.
Nielsen argues that hidden navigation (hamburger menu) significantly decreases user experience both on mobile and desktop. On mobile, people used the hidden navigation in 57% of the cases, and the combo navigation in 86% of the cases, i.e. 1.5 times more! The combo navigation that Nielsen refers to is a tab bar pattern combined with a hamburger menu — here’s an example:
The Samsung app example from Rizki Rahmat Ridha for Muzli (Large preview)
It might seem like the tap bar is the perfect solution, but it has its problems too. Fabian Sebastian raised a good point that it only works on top-level views. It does not work with secondary navigation items. To solve this problem, a hamburger/tap bar hybrid was born. If you pay attention to the Samsung app, you’ll see that the last item on the menu is the “*More*” button which calls up the hamburger menu.
In essence, the bottom navigation pattern integrates quite well into the tap bar pattern if you want to combine both of them. The best place to look for good examples is in the mobile app world.
Some Popular Websites Reimagined
I opened up Photoshop and did a quick mockup of a few popular websites in order to explain that changing the navbar to go bottom-up is not that difficult.
The Reddit website with a reimagined bottom navigation (Large preview)
Yes, this idea does raise questions, but it’s simple enough to be adapted to the web. It does make a usability difference as the interaction cost is much lower.
That Sounds Great, But How Do I Convince My Clients?
You, as the designer, might see the potential of this pattern, but what if your client or your boss doesn’t? I would answer this problem with a couple of arguments:
Mobile apps have been placing valuable menu items to the bottom for years already. Just send them these two articles for starters:
I had noticed cases in which popular mobile apps started to shift important bits to the bottom. A good example is Uber. For them, the search bar is one of the most important items on the screen. In the old design, its position was at the top. Now, they’ve shifted it to the bottom. Could we be on to something here?
The old and new Uber search bar design (Large preview)
Shifting important navigation items to the bottom is not a new thing in mobile app design. It’s just that — for some reason — the web industry has not caught up on this just yet.
Summary
The facts are quite clear: Phones are getting bigger, and some parts of the screen are easier to interact with than others. Having the hamburger menu at the top provides too big of an interaction cost, and we have a large number of amazing mobile app designs that utilize the bottom part of the screen. Maybe it’s time for the web design world to start using these ideas on websites as well?
I understand that all of this is not a foolproof solution for all use cases, but it’s worth a shot. It helps make the experience just a tad bit better. I’m interested in hearing your thoughts below!
It isn’t uncommon for designers and developers at agencies to clash when building a website — that is, if their collaboration process isn’t streamlined.
As the designers crystalize the look of the site’s front end, they could overlook the functionalities that the developers are hard coding on the backend of the site, causing conflict between the site’s functionality and design. And as the developers code the prototypes that designers have mocked up, they might misunderstand what the creatives had in mind for the way elements interact or resize at different screen dimensions, frustrating designers.
Sure, the convergence of software for prototyping and coding has made these dynamics less contentious than they once were, but software alone won’t solve all your problems. The potential for tensions still lurks, and conflict can escalate rapidly. This can lead to all sorts of problems for the agency manager, such as quarrels in the office, client complaints, missed deadlines, or subpar work.
When all is said and done, it all boils down to your team getting frustrated, your agency losing revenue, and your brand reputation getting smeared.
It’s precisely because of this that you need to streamline how your designers and developers collaborate. And to make that happen, you need to have a clear set of expectations – and the tools to implement them. Here’s the process we recommend.
1. Set up SLAs and Project Wikis.
In the context of this discussion, an SLA (or Service-Level Agreement) is basically the commitment/agreement between your development and design departments. While there are several types of SLAs, we’re going to zoom in on internal SLAs, since we’re talking about improving how two of your organization’s teams collaborate.
The agreement contains what each party commits to deliver to the other and expects to receive from the other. It covers several components like the output that will be provided, the desired measurable quality of the output, the responsibility of each party, the repercussions if the service is not provided, etc.
SLAs are great, since they help ensure everyone’s expectations are aligned. The first step to creating an SLA is to have a meeting with both parties so they can hammer out the expectations and requirements. These can refer to technical requirements, such as file formats and specifications, or they can focus more on workflow and division of labor issues, such as turnaround lag times for various phases of projects.
With an SLA in place, both your designers and web development teams can operate with a level of autonomy, since they know what is expected of them, even without consulting the other department.
Now that we have the SLA bit cleared up, it’s time for you to set up your project wikis. Basically, project wikis are like central filing cabinets with truckloads of important resources that your team members can access any time. This is where you store your SLAs, standards, policies and project assets.
Whenever your designers or web developers are uncertain about something, they can revert to the relevant wiki to make sure that what they’re doing is well within the standards they established, and the output they’re producing is acceptable to the other department.
To help you put together your project wikis, you can use a documentation collaboration tool like Notion. The platform offers a free tier and it’s very easy to use. Notion has several templates your team can use for wikis associated with website build projects.
You can store your documents here so everyone can access them at any time. You can also set permissions for who can view, comment, or edit your files.
By establishing SLAs and using a tool like Notion to set up your project wikis and improve your collaboration, your design and development teams will have all the terms spelled out for collaborating more cohesively.
2. All parties should work together from the get-go.
In most cases, designers have the first crack at creating websites for clients. They are the ones who do research into UX trends in the client’s industry, who create thumbnails and wireframes, deliver mockups, and refine these concepts with the client.
Once designers have finalized how the client’s website to look and function, only then do they hand over the details to the developers, and that’s when tech feasibility assessments and coding processes begin.
But the default workflow described above can be a big mistake.
The thing is, the plan that the designers came up with might have been awesome, but from the developers’ point of view, it’d be impossible to pull off. If not impossible, it’d be too time-consuming or costly, when pegged against the allocated budget or manpower hours for the website.
It’s because of situations like these that designers and developers should be collaborating from the get-go.
As the designer conceptualizes, the developer should also be there validating if the designer’s idea is feasible or not. That way, everyone is on the same page and everyone knows with certainty that the concept the designer came up with is doable – as part of the client-facing planning process.
3. Use a teamwork-friendly production platform.
The same thing happens, no matter what. It doesn’t matter whether your team uses some kind of WordPress sandboxing solution, a prototype-to-production tool, or a dedicated multisite design platform to build out websites. At some point (hopefully quickly), the client will approve your plans, the prototyping phase will be complete, and it will be time to actually build the site.
Is the software you use for this optimized for efficient building of user interfaces and functionalities? Is its purpose primarily to convert file formats and hand off assets from designers to developers, so as to minimize the need for custom coding? Or is it more than that, a solution made for maximizing stakeholder visibility and scaling production processes over time?
Teamwork, after all, is an absolute must for building a successful agency. With a reliable website builder platform that allows for a more streamlined team collaboration, you’ll experience far fewer hiccups during your website creation process.
Duda is a web design platform for agencies bent on scaling business. It has a wide array of features for building websites, managing clients, and team collaboration. To improve how your team works together, Duda has an instant messaging feature that allows clients, marketers, designers, and developers to chat about the project from within pre-launch versions of the site.
Duda also makes it easy to customize page layouts, widgets, and even full website templates, all of which you can save to shared libraries so that your team won’t have to build things from scratch every time a new project starts.
4. Hire a competent project manager.
Sometimes, the reason why your web designers and developers don’t get along is simply that they are managed poorly. Either the project manager is slacking off, or he/she just doesn’t know the psychology behind empowering people and building a cohesive team.
It’s important for your agency to have PMs who wield interpersonal influence over your designers and developers. This allows them to establish meaningful relationships with both parties, and even build bridges to help collaborations between the two-run smoother.
And so the question becomes, where are you supposed to find a reliable project manager? One who can gel your designers and developers together? While it’s primarily used for one-off gig work, Upwork could be a great place to find your ideal project manager.
The platform features literally millions of freelancers who can help you with varying tasks like writing, social media marketing, web design, web development, and… you guessed it, project management.
There are freelancers on Upwork who are tried and tested to produce exceptional work.
Just by looking at their job success rates and the amounts they’ve earned, you’ll have an idea of how seasoned and reliable the freelancer is. You can also view the feedback/reviews the freelancer has received from prior clients.
With a robust freelance marketplace platform like Upwork, it’ll only take you minutes to shortlist competent PMs.
What’s next?
While it might be challenging to run a team of web developers and designers, it is not at all impossible. With the help of the right strategies and tools, you can pull it off swimmingly and be on your way to scale your agency to greater heights.
