When I began developing Wolfram in June 2021, I was presented with a new issue: webapps. I'd never developed a full-page webapp before, so I had no idea how to optimise it for mobile and was basically back to square one in terms of code modularisation. I picked a great deal up when developing Wolfram I, so when I redesigned the interface for Wolfram III it was a great deal better, although it didn't at all work on mobile devices, and the codebase was messy.
So, when I was staring down the barrel of redesigning Wolfram's UI yet again to make it compatible with mobile devices, I decided to sit down and develop a proper, fully-fledged design engine that was built from the get-go to do everything I needed it to. This was Phosphorus.
Any sane person in web development would understand just how painful writing accessible webpages truly is - devices come in so many different shapes and sizes that it's nearly impossible to develop a perfect website for all of them. As a result, many developers choose to use a third-party system like Bootstrap or a React library to do the heavy lifting work when designing a page.
I didn't want to use an existing library, however - and there were a few reasons for it:
- Originality: It's very easy to build a generic-looking website with an existing design system, and I wanted the freedom to make something original.
- Workflow: I design almost every page down to the pixel in a vector program, before I even open a code editor. It allows me to absolutely nail the look of every page, and removes the guesswork from writing HTML and CSS at the same time. Using another design system would mean I couldn't do this as accurately.
- Familiarity: The ad-hoc design system that I wrote allowed me to go from a completely designed site schematic to functional and published site in under 3 hours in some cases, with individual page development times being minutes, not hours. Imagine what I could do with a purpose-built system!
I started designing Phosphorus in September by designing what I wanted Wolfram V (the latest redesign of Wolfram) to look like. To describe the exact design process to build for both desktop and mobile-class devices is difficult because it required a lot of back-and-forth between what can be done from a design standpoint, and what should be done from a usability and practicality point of view.
Wolfram III (left) was designed on my ad-hoc system and worked great on desktop, but was unusable on mobile. I intended to fix that with Wolfram V (right).
This comparison should explain a lot of the changes that I made while still in the design process, many iteratively.
I dropped the monospace font because, while it had a "techno" personality that I liked, it wasn't practical to read: monospace is naturally wider than regular fonts so it just took up more room and wasted space. A lot of decisisions were made to move from "riskier" input methods and layout systems back to tried and true systems throughout the process, not only to make development easier but to give a user what they would expect to see from an input.
I did make some bolder choices when redesigning Wolfram, though: the horizontal menu buttons ("set", "routine", "view", etc.) were removed and replaced with a vertical, icon-only navigation rail. This decision was made for the primary reason of maximising the vertical space that the primary page content has access to, which I found reduced the difference in both design and usability between a mobile and desktop device (the nav rail would move to the bottom and the sidebar would move to a popover on mobile devices). This change did of course come at the expense of quick usability - writing out the words for the page is more immediately understandable as to their function, but given Wolfram (and most webapps I'll be designing with Phosphorus) have only 4-6 pages, I figured a user would quickly learn to associate the pages with the icons instead of the words.
There were also a few changes that didn't make it to the final version, notably outlines. Originally, I designed it so that any element with an outline would indicate that it was interactible; buttons, sliders and cards would have them, but not containers and layout elements. I removed it, however, because I found it made a negligible difference to usability, but added a "corporate" look that dated the whole design a fair bit.
With most of Wolfram V designed by mid-September, I started actually creating the substance of Phosphorus in a dedicated project that contained only the design elements. It's worth noting that the next segment gets fairly code nerd heavy, but I'll try to explain everything as best I can.
dependencies.css- This contains all the underlying CSS variables for the project, including colours, corner rounding and animation speed. Colours are tied to the user's preferred colour scheme so that darker colours can easily be displayed for devices with a dark mode enabled.
framework.css- This file contains the core elements of Phosphorus, such as input elements and basic layout systems. It's universal across both disciplines of Phosphorus (I'll get to this shortly).
app_framework.css- These files contain the overrides and layout elements required for the individual disciplines of Phosphorus. You may remember that I mentioned two very distinct use cases for my ad-hoc design systems up top, and this was how I could create a single system that could function across both.
global.css- This file held all the project-specific elements and overrides required.
Oftentimes, individual pages would contain another CSS file stored elsewhere that contained unique elements and overrides for that page (like a local
Up until this point, I've only talked about designing Phosphorus for Wolfram and other webapps, however I regularly develop "traditional" websites (such as this isaacshea.com!), and wanted a unified system that I could use across both. Originally I was going to use only one discipline to do both, but as I continued designing Wolfram I realised that the differences between a website and webapp run too deep to do that.
The web framework handles the
nav element as a nav bar, whereas the app framework handles it as a vertical rail.
I think the most notable example of this is the
nav element, as it's called in CSS code. In the web discipline, a
nav is a horizontal series of text buttons across the top of the screen that allow a user to navigate between pages. While the functionality remains the same in the app discipline, the implementation is different; an app
nav is a vertical rail that houses icon buttons across the left of the screen on desktop devices, and across the bottom on mobile devices.
However, I got a bit carried away and wanted to implement an object-based system that would allow me to read the values of inputs with far less effort. To cut a confusing and ultimately unnecessary story short, I didn't implement it very well and as such spent a lot of time on a feature that is broken and unusable.
To put a bow on it
There's a great deal more content I could dive into about Phosphorus that would be far too technical to explain here, and I could get nitpicky about all the things I'd change if I were to do it over, but instead I'll leave some final notes about what I've learned and what I'll improve in the future.
The difference between Wolfram I and Wolfram V is so astounding that I wonder how I considered myself a designer 12 months ago.
From a design standpoint, my taste in design is evolving rapidly and as such Phosphorus will visually evolve over time. The above images showcases just how much Wolfram's design has evolved over the course of 2021 alone, so I'm sure everything will evolve in the future.
Something I've already started designing is more unique interaction methods; and not just for the sake of having unique interaction methods. I keep coming back to it, but the vertical nav rail for the app discipline of Phosphorus is an example of making a newer, "riskier" interaction method, not to be unique for the sake of it, but to push the limits of user interfaces.
Another thing that I'll be improving upon greatly in the future is personality: Wolfram V looks a little too "corporate-y" for my liking, and I'd like to come up with a healthy middle-ground between the [over-designed UI concept every Instagram designer loves] and the super-practical but really boring interfaces that is ever-present with Apple SwiftUI development, and I think that designing unique interface elements plays a big part in that. I like a functional webpage as much as the next guy but if I could do that while adding a bit more "indie flare" to it, I surely will.
Yes, if you use a Taskmaster application on an iPhone with rounded corners, the corners of some elements will round to fit the phone. Yes, I spent far too long figuring out how to get it right.
From the perspective of the codebase, a lot of work can be done. One massive change I'll be making (perhaps before a major rewrite) is re-arranging the CSS codebase so that individual elements or element variations can be imported seperately. This would reduce page loading times by only loading necessary content, and reduce the overall project size by only having files for elements that are used. It would also mean that the variations of elements such as the nav can be imported seperately, removing the need for two explicit disciplines like there currently is.
For the moment, however, Phosphorus is an excellent system considering it's my first real dive into a fully-developed design system. It's closed source and at work holding together my personal website, all the Taskmaster apps (including Wolfram), and any commissioned websites that I make.