We started in early 2020 revamp our website. After a couple of ideation jam sessions, the seed of the concept rose in the form of a hasty model (see above).
It lacked polishing, it replaced ambition – showing where MAD was able to move to the “work” section without a visitor. In this case study, we reveal our process as well as the challenges our small 6-person team faced in a year-long (page) project.
Ideas and parameters
Once we had decided on the idea, we set out to write a vision our websiteWe could look back and measure our work every few weeks. Ideas can be easy to get under favorable conditions, but too often ideas remain ideas or do not fulfill the purpose for which they were designed. Ideas need to be measured, validated and continuously developed. Those who survive development or careful pruning will form the strongest foundation and will do better in the future.
This gave us enough direction to start the experiment. Challenges creating a pseudo OS desktop-as-a-website was presented in many different formats, starting with how to maintain a hierarchy on a confusing desktop, and how to handle detailed pages. We wanted this website to show how closely our design and engineering teams work with each other, so we involved the whole team from day one, taking advantage of ongoing feedback loops and jam sessions at Figma. Below, you’ll see a few of our “playground” Figma documents that illustrate how we iterated and iterated until we felt fulfilled by the vision outlined above.
The challenges of creating a Pseudo OS desktop website took many forms.
Improving design – data vs. intuition
We firmly believe that intuition and experience should guide decisions. This means that we only use data collected from UX interviews to back up our intuition. Too often, designers are knowledge-based, hoping that complex and numerous concept documents will save the day instead of thinking and repeating their solutions. In practice, this means that we study extensively and loosely before repeating those studies until they seem right.
As you can see from the GIF image above, we made several stylish attempts at our dashboard design style. Even though we had landed on the style of our choice at a really early stage, we took a few days to try out alternative models just to make sure we had made the right decision initially. When I had time to try this a lot, it really affected the overall quality of the final product.
We are huge supporters of practical solutions. As part of the original concept, we decided to use Apple Memojis instead of team photos. They’re fun, easy to create, and much more effective than inviting a photographer to each new team member. It’s neither a new idea nor wild, but with a website like ours, it seemed the most logical solution.
Creating an essential set of windows in a browser window posed an interesting challenge. We had to make sure that 0.1% of people who drag their browser windows to different aspect ratios to test the responsiveness of a website would be happy with the way the windows moved and organized. We also had to make sure we maintained a certain hierarchy in the z-index so that the buttons were always up. First we divide the modules according to priority, then our design team built a few different tools that allow the design team to move modules in a website test example and save the coordinates of those modules (for use in the final version). the user started playing.
Creating an essential set of windows in a browser window posed an interesting challenge
The value of prototypes and happy mistakes
Our 404 page is a visual reminder of why we ensure design and planning go hand in hand from day one.
The idea was presented half a joke and half a challenge for our engineers. The result is something that design or technology didn’t initially imagine. The fun 404 page, which consisted of interactive radio switches, became an interactive drawing tool … mostly a mistake and an abuse. Recently, we have found that we have been able to take advantage of these lucky results more and more for our clients.
Half pixel edges and browser compatibility
Our design made extensive use of half-pixel edges, but unfortunately only Firefox and Safari support fractions of pixel widths at the edges. That’s why we decided to fake these using a box shadow. This worked well in all browsers, and some custom CSS features made it easy to use different variants on the site and fine-tune them together during a call.
Everyone’s favorite, QA. It’s hard to put into words how important a solid quality assurance process was to the success of this website. It took a whole month to fine-tune, polish and push and break and repair all the elements until the website met the level of quality expected from us. Several devices, Linear, Tuple, and Tailscale, made this daunting process more manageable.
One thing we realized pretty late in the process was that the Window Driving Interaction required different adjustments to make you feel better on the tablet than the ones we had already implemented for mobile devices and computers. On the desktop, windows can be dragged in the usual way. If you use the same technology on mobile devices, the windows will move when you just try to scroll. Therefore, we added a long press to start the mechanism and timeout pull on the mobile device.
However, the same mechanism seemed slow and did not respond to the tablet, where we had the display property of almost small desktops, but the interaction model of mobile devices. To solve this, we sat down with the call for hours, shared the localhost in real time with each other using Tailscale, and reloaded the site on all devices after each change to see how it felt. In the end, this allowed us to find solutions that felt good on different devices.
The biggest challenges we faced were performance-related. The modules slowly pulled around when there was blur in the background, and pulling them affected the smoothness of our background shadow animation.
We optimize these aspects to create a smoother experience:
- Make the client-side rendering more detailed just by wetting certain parts of the page with custom elements. This significantly increased the time for interaction. Examples are standard issues such as a
or but also elements such as (for background shading) or (for the homepage note applet).
- Disable the CSS background filtering effect in Chrome because it significantly slowed down drag-and-drop performance compared to Safari (Firefox does not yet support a background filter from the package).
- Pause the background shadow when dragging modules on the landing page to make it easier for the browser to calculate background inaccuracy.
- And then numerous standard optimizations, such as using the Sharp library to dynamically resize and compress images based on screen size, or sensible use of preload headers.
MAD– Design and development for each screen.