The first unit in our course on Advanced Design and Prototyping focused on Value-Sensitive Design, and a couple of the assignments we did as part of it were pretty fun.
The first was to do a sketchnote on the concept itself. I’ll admit, I was a bit skeptical of the concept of sketchnoting – I thought it would be fun, but I didn’t think it would actually be all that useful. In doing it, however, I found that it helped me to coalesce my thoughts a bit – though, admittedly, that may have more to do with the fact that it forced me to go through my typed notes again than the sketchnoting itself. Still, it was a fun way to do that bit of studying, so I think I’ll try to add it to my workflow in the future.
Another activity was to put together a presentation, going through some value-sensitive design processes and presenting our ‘findings.’ Of the available prompts, I chose the one that boiled down to “your team has just been hired to design a photo-sharing application; you’re in charge of the VSD portion. Go.”
The second unit in my course on User Experience and Evaluation was on competitive analysis — looking over the competitive landscape in a given marketplace, and using that data to figure out both the low-level design and high-level strategy you should use to effectively compete.
While I considered doing an analysis of the productivity management/to-do-list marketplace (an area on which I havemanyopinions), I realized that the end result of that analysis would be “the marketplace is saturated, and the ‘table stakes’ level of functionality is prohibitively expensive to achieve.” Not the most exciting result.
Instead, I looked at another area where I’ve gone through a surprising number of apps: fitness tracking. Specifically, workout planning and tracking – I did a previous assignment on how people use the gym, and one of my findings was “hoo boy are there a lot of different systems for planning and tracking a workout.”
After downloading quite a few apps and compiling a rather monstrous spreadsheet, I put together the results into a report, which I’m now posting here.
(Will I be using these findings to develop an app? … No comment.)
For those using screen readers, or who prefer their own reading environment, you can download the full presentation PDF here:
As a recent assignment for one of my design classes, we were told to find a website whose design we didn’t like, build a moodboard for a new version of the site, and then create a high-fidelity prototype of the new version of the page we’d called out.
For my uninvited redesign, I selected Calibre’s homepage; I love what Calibre stands for, but I haven’t used it in years, because… well, I’ll just drop in my analysis portion here:
It could use some love, is the short form of it. (After I built that and submitted, I realized I’d forgotten to turn off my content blockers for the screenshot; the unaltered version of the site looks the same, but also features ads along the side, which explains that awkward hanging line in the latter screenshot.)
Next up, build a mood board. This was pretty fun to do – I basically just wandered around, not only the internet, but a nearby library, and my own bookshelves, looking for inspiration. Here’s the result:
I couldn’t not pick Baskerville, c’mon.
The final part of the assignment was to put together our own redesign, using what we’d put together in the mood board. I almost sat down with Sublime and coded it in HTML, because that’s what I do in my day job, and it’d be easy, but made myself use Sketch instead – what better way to learn than by practicing?
That’s the end, right?
Well, no, if you looked at the featured image on this post, you already know I did a bit more. The extra credit portion of the assignment was to do a redesign of a different part of the brand; I opted to do a quick take on “Calibre, if it was designed for macOS”. (For reference, Calibre was designed for/using Qt, which means it looks somewhat out of place… basically everywhere.)
(I would like to clarify – I’m throwing a lot of shade at Calibre here, but I really do respect what it is, does, and stands for. DRM-free ebooks are a very good thing. Support your authors.)
This last bit was, in no small part, just an excuse to play around with the Sketch resources that Apple provides. They’re neat!
As I’m sure I’ve mentioned, I’m currently working on a master’s in design. (I’m not sorry for talking about it a lot, I’m excited!)
In the first week, we spent a lot of time sketching. Which is… not something I’ve done a whole lot of, in the past; a bit here and there, especially while I was planning out Fluidics, and I do some at work on occasion, but never as much as we did in that first class.
One of the things that our professors mentioned was that it’s something that takes practice. Which, duh, except I hadn’t really thought about it like that. I’d done the thing that so annoys me when people do it with music: "oh, I’m just not talented at that."
That’s wrong. It’s not that I’m not talented; it’s that I’ve never practiced. So I made a resolution of sorts: I’m doing a degree in design, sketching is an important skill in design, so I’m going to practice this skill. I added it to my habit tracker, and off I went.
Since then, I’ve been trying to do a sketch every day. Mostly sticking with pencils (or rather, ‘pencils’; most of these were done in Moleskine Flow – it’s a pretty good app for this, and I’m quite enjoying the Apple Pencil), a bit of pen here and there. And sketching whatever catches my eye – there’s a good deal of the random items around my house, and a small collection of light fixtures in the various Starbucks’ I’ve found myself in over the past month or so.
It’s been fun. And, looking back over my sketches to put this post together, I think I’m improving. So, hey, practice: it works!
In my Design and Prototyping class, we recently did an assignment called "Add a Feature". We were supposed to take an app or site we frequently use, find a competitor or two, and identify a feature that the competitor has. We would then sketch our take on that feature, if it were added to the original app, and wireframe it in Sketch.
As my original app, I chose Things. I’ve been a user, and fan, for years. I have also, however, tried OmniFocus, and know there’s a feature there that I would love to have in Things: sequential tasks.
The basic idea of sequential tasks is that you can set a project, or a group of tasks, to operate in parallel – the normal way, where you can see all the incomplete tasks – or in sequence. When they’re in sequence, you can only see the next incomplete task, not all of them.
Which would be very helpful to me, at the moment – I’m taking classes, and a lot of what’s going into Things at the moment is "do this reading, watch these lectures, then do this assignment." Except, of that sentence fragment, things doesn’t support the word ‘then’, so I see the whole list all at once. I’d rather only see the reading, then only see the lectures, then only see the assignment. Perfect candidate for the assignment.
So, first thing’s first: sketch it.
I kicked around a couple different ideas, but pretty quickly arrived at the conclusion that it should be integrated into Things’ ‘When’ menu.
The other question was how to display these in the list. The point, of course, was that sequential items wouldn’t show up in the ‘Anytime’ list, but they do still need to be visible in some circumstances – namely, when you click through to the project itself, future items still show up.
I actually tried a couple variations – it’s at this point that, were I working for Cultured Code, I’d say “we should build both versions and do some testing to see which is better.” I’m not, though, so I just wireframed them both and turned in the result.
I’m fairly happy with the way I integrated it. Clicking, tapping, or typing “After” pulls up a second menu, where you can search for the item you want to attach to. Instead of thinking about it in terms of the project, the mental model is just “after x, I’ll do y.”
All told, I really enjoyed this exercise – it was the first wireframing I’ve ever done in Sketch, and it was neat to think about integrating a feature into something I use all the time. (And, hey, Cultured Code, if you’re reading this: feel free to use this idea, because I’d love to have the feature.)
I recently started a Master’s in Human-Computer Interaction and Design. While the main goal of the program is, obviously, learning, one of the side goals is to build a portfolio; as such, I’m going to be making an effort to post some of what we’re working on in class here.
One of our assignments was to start collecting images and clippings, and doing some annotations of them. The idea is to build up a library; something like Quiver, but for design instead of development. It was actually very fun; a lot of my classmates did it handmade, and I considered it, but I’ve also been meaning to try Adobe XD and figured, why not?
It’s a pretty neat tool, it made it very quick to put these all together. Much more focused than my other digital go-to, PhotoShop, where I probably could’ve accomplished the same thing, but would’ve spent more time digging around in the ‘draw a line’ settings and whatnot.
A lot of what I did for mine were mobile apps – that is, after all, my main area of interest – but I also made an effort to branch out to other operating systems and even (gasp) physical devices.
A big part of the assignment was giving feedback to our classmates on what they’d collected. The goal wasn’t “hey, that’s a cool interface you were looking at,” but “oh, that’s a good point about the interface.” The exercise, after all, was about the act of collecting and annotating.
It was interesting to see how everybody did theirs – most of the people I talked with had done them by hand, although somebody did a lovely blended style one by collecting screenshots and photos and then annotating them with an iPad and Apple Pencil.
I’m not sharing all of what I’ve collected here – I’m proud of my annotations of the to-do list app I use, but I don’t actually want to share the contents of my to-do list. And while I had fun marking up Dark Sky, I don’t feel the need to share my home address with the internet.
I’ve got some pieces from my sketchbook that I might post sometime soon, and I’ll hopefully continue to have interesting things to share as the program goes on!
The first major update to Fluidics is now available on the App Store!1 In all honesty, it was largely a ‘bug fixes and performance improvements’ update, but I’ve always hated when app updates list that, so I made sure to include a couple user-facing features so there’d be something fun to talk about, at least.
In this case, those features were animations. The most notable is the background – rather than being drawn once, the ‘water’ in the background is now animated, which I think makes the visual effect much nicer overall. Swiping between the three main pages of the app is also much smoother now; instead of a single ‘swipe’ animation being triggered by any swipe, it directly responds to your swipe, so you can change your mind about which direction to swipe halfway through, and it feels more like you’re moving things around, rather than switching pages.2
The big changes, though, are largely invisible; a whole lot of work on the internals to allow for future features I’m planning.3 The gist of it is that a lot of the internals of the app are now a separate library, which means I can share code between the widget and the main app without needing to copy-and-paste all the changes I make in one place to the other.
Past that, there were a couple little tweaks — the algorithm that calculates the water goal is a bit less aggressive with the way it handles workout time, and there’s now a little “this isn’t a doctor” disclaimer in the Settings page that I put there because the lawyer I don’t have advised that I do that.
And, the bit that turned into more of a project than I thought: VoiceOver support. VoiceOver, for those that don’t know, is one of the core accessibility features of iOS; when enabled, it basically reads the contents of the screen to the user, making it possible for visually-impaired people to use iOS. By default, any app built on UIKit has some support for VoiceOver, but the further you go from the default controls, the more broken that’ll get. The way Fluidics works, it was super broken; technically useable, but downright painful to do. After a day or two of vigorous swearing and arguing with the Accessibility framework, I’m proud to say that Fluidics is now VoiceOver-compatible.
If you’ve already got Fluidics on your phone, it’s a free update from the App Store.4 If not, the whole app is a free download from the App Store, and I’m hoping that you’ll enjoy using it. Leave a review or whatever; I’m trying not to be pushy about that.
Oh, and I’m in the process of updating the app’s website; I got such a good URL for it that I want it to look good to match.
There was a bugfix update earlier, version 1.0.1, but that’s not at all exciting, so I didn’t bother writing anything about it. ↩
If you’re curious, this involved rebuilding the entire interface, from three separate pages that’re transitioned between to a single page that’s embedded in a scroll view. ↩
And no, I won’t be telling anybody what those are just yet; I don’t want to promise anything before I know for sure it’ll be possible. ↩
In fact, it may have already been automatically updated — the easiest way to tell is to open the app and see if the water is moving or not. ↩
Now that the whole concert is over, and I’ve finished going through approximately all of the WWDC sessions, I’ve decided that Variations won’t be receiving any further development — it wasn’t going to be enough of a priority for me to do it any justice, and I’d hate to half-ass it.1 The app will remain on the App Store, for now, though if it breaks in future iOS versions, I’ll probably pull it entirely. Instead, I’m releasing the source code, as-is; if you’d like to look through it, it’s right here.
I had fun building it, and I like to think that it does some interesting things with the implementations under the hood, so hopefully somebody can find some use from it.
This is, hopefully, a hint about some of my other projects that are a higher priority; announcements of those will, of course, show up on this here blog. ↩
Tap here to download the app on the App Store!
I have always been fascinated by the emergent properties of mathematics: simple rules create complex structures. When you get down to it, this is how all of our modern technology works. Variations is based on that concept and was composed for performance through an application written for the iOS® operating system.
At the core of the application are cellular automata based on Conway’s Game of Life (1970), which is a grid where each square is either ‘on’ or ‘off’ and follows a strict set of rules. A square that is off (‘dead’) can become alive (be ‘born’) if it has the right number of living neighbors. A square that is alive can die if it has too few (loneliness) or too many (starvation) living neighbors. The rules are simple, yet they can create astonishingly complex patterns; there is an entire field of mathematics devoted to studying these patterns, Automata Theory.
Variations allows these patterns to play out both visually and aurally. Tap the screen to allow the grid to move through another cycle of living and dying, or just listen to the music created by a single frozen moment. No two people will ever hear the same set of sounds: the starting point for the patterns, as well as their evolution, are uniquely generated every time the Variations application is run.
I made an app! I’m quite excited about it; this is, after all, the sort of thing I want to spend my career doing.
The app is called Fluidics, and it’s for tracking the amount of water you drink. As I mentioned a while back, I like to do a lot of tracking of what I’m eating and how much I’m drinking. That first part wasn’t too hard; there’s a variety of apps on the App Store for logging food, and after a while I was able to find one that wasn’t too bad.1 For water, though, nothing quite worked – Workflow came closest, but using it to do the sort of goal calculations I wanted was on the line between clunky and painful, and it’s such a general-purpose app that it felt visually lacking.
Eventually I remembered that I’m a computer science major, and why am I sitting around complaining about the dearth of options when I’ve basically got a degree in making the dang thing. Months of sketching, programming, swearing, and repeating the whole thing eventually lead to this: what I hope is the easiest water-tracking app on the App Store to use.
One of the most interesting debates I had with myself during the whole process was deciding what business model to use.3 The App Store has had an unfortunate tendency to be a race to the bottom; while there’s a bit of a market for pro apps, a minimalistic water-tracking app doesn’t fit into that category. There’s also no argument to be made for a subscription, so I’d narrowed it down to ‘free, because I’m turning it in as the capstone project for my computer science major’, ‘free with ads’, or ‘paid up-front’. The first one was the one I was most comfortable with; sure, ‘paid up-front’ would be nice, but I’d also get approximately zero people to download it what with all the free competitors out there. ‘Free with ads’ feels deeply gross, both because I hate online advertising in general, and because I’m doing a lot with health data, and I really don’t want to have any chance of that getting stolen. For a while, I thought it was going to be ‘free forever’, and I’d be justifying it as ‘building a portfolio’.
That wasn’t what I actually settled on, however; instead, I’m going with ‘free with in-app purchase.’ Instead of building in a paywall and locking some features behind it, though, I decided I’d go simpler; the app and all of its features are free. Starting in version 1.1, there’ll be a button in the Settings; a little tip jar.4 I probably won’t make much, but I’ll feel better about it overall, and what’s the harm?
Beyond that debate, most of the challenge of the project as a whole was just building it. I knew going in what I wanted it to look like; what I didn’t know was how to go about doing that. The way the background overlaps the text? That alone took a week of trying different things to get working right.5 A few things I wanted to include in the first version didn’t make it – the widget was originally going to be entirely different, but the way Apple has done the security on health data makes the original design significantly more difficult to do, so I switched it to the current design.6
It was definitely a learning experience, too – I’d done some iOS application design for classes before, but never gone all-in on making something that would be both functional and enjoyable for the end user. If you’re releasing something on the App Store, you can’t just include a note that says “on first run, it’ll ask for a bunch of permissions; just say yes” because nobody will read that. And getting something uploaded to the App Store is itself a whole process – the App Store page doesn’t fill itself out, after all, and copywriting definitely isn’t my strongest suit.7
But it’s done; I’ve made an app and released it to the world. 8 By the time you’re reading this, it should be available on the App Store; as I mentioned, it’s free to download, and I’d love it if you’d give it a try.
That said, I’m also doing some design sketches for my own entry into the field; don’t get your hopes up, I make no promises. ↩
I’m not talking “my code is full of bugs and something crashed” went wrong, either; it’s all “the user originally gave permission to do something, but then changed their mind and used the Health app to take it away” and other such nonsense. Computers may be finite-state machines, but “eleventy hojillion” is still a finite number. ↩
I also talked about this a lot with my friend Chase, without whom I would’ve long ago given up on technology and disappeared into the woods to be a Bigfoot impersonator.. ↩
Yes, I know, I’m just now releasing version 1.0, and I’m already mentioning plans for 1.1. Don’t worry, I’ve got versions 1.2 and 1.3 mapped out, feature-wise, as well, and have some rough ideas for 1.4. ↩
For a while I thought I was going to have to write code to draw the numbers ‘by hand’; fortunately, I was able to get the drawing to work by taking advantage of layer masks, but good lord are the Interface Builder files a mess as a result. Behind The Scenes, everybody! ↩
I do still want to get the original design working, probably as an option in the Settings page of the app; a future version is going to add watchOS support, and I believe that a lot of the work I’ll have to do for that will also apply to making the widget work like I intended, so those two will either be the same or subsequent updates. ↩
Another shoutout to Chase, who wrote the App Store description and turned my pile of 100 disjointed screenshots into the four that’re currently on display. ↩
Well, “done”; it’s functional and available to the public, but software, as the saying goes, is never finished, only abandoned. I’ve no plans to abandon this project anytime soon; I use it myself several times a day, so I’m pretty invested in keeping it working and making it better. ↩
This month I’m working with the Castleman Quartet Program as their intern and liaison to Linfield College. Part of what they’ve got me doing is publicity, including designing posters to advertise their upcoming concerts.
Which, as it turns out, was a bit of a fun challenge, as we don’t have a color printer, so the design had to be in grayscale only. We’ve also got two concert series – one of chamber music, and one of solo music – and while I wanted the two posters to be clearly related, I didn’t want them to be identical, because that would lead to people glossing over one or the other, assuming it was just another copy of whichever one they’d seen first.
Here’s the result:
Oh and, of course, the concerts are open to the public, free of charge, so if you’re in the area, feel free to come by!