Tag: IN4MATX287

Categories
Portfolio Video

JupyterLab Presentation

JupyterLab logo over three icons. From top: Ceilings - where am I? Bridges - where's my stuff? Spaces - what am I doing?

Part of the MHCID’s program requirements is that we give a presentation, detailing what we did during the internship. This year, gathering everyone together for a TEDx-style event… wasn’t in the cards. Instead, each group made a video presentation, filling approximately the same niche.

It’s been a while since I had a chance to do any video editing, and I had fun putting this together. As mentioned in my previous posts about this project, it was a group effort – we each recorded part of the audio, and split up the work of finding video clips, icons, and images to go with what we were saying.

It was fun to put together, and I’m pretty happy with the end result. Check it out:

Watch the video
Categories
Portfolio

JupyterLab File System Prototypes

Image from the JupyterLab FS high-fidelity prototype, showing the first page of the prototype.

Summer quarter has come and gone, and with it, I am now a Master of Human-Computer Interaction and Design.

As I did at the end of last quarter, I’d like to take a moment to look back on what we’ve accomplished this quarter.

And, a refresher on who “we” is in that sentence:

And myself, in a design role.

Having done all that research during the spring, summer was about prototyping and iteration.

Low-Fidelity Prototype

Image of the opening screen from the low-fidelity prototype of the JupyterLab File System

The term “low-fidelity prototype” might sound a bit negative, but they’re a wonderful, wonderful thing. Low-fidelity prototypes are easy to make, which makes them easy to toss aside. In the same way that you use sketches and wireframes to go through a lot of ideas very quickly, a low-fidelity prototype lets you try things out without pouring a ton of resources into making something pixel-perfect.

We went through several iterations, developing clickable flows that highlighted the key points of the features we were designing. Those flows in hand, we went back to the users, and gathered more test data – did they understand what the new features were for? Did the terminology and usage make sense? Was it useful?

High-Fidelity Prototype

Image of the opening screen from the high-fidelity prototype of the JupyterLab File System

That user feedback in hand, we went back and created a high-fidelity prototype. One of the main goals we had in mind with this was to have it, if not ‘pixel-perfect,’ viable for handoff to the developers who would be creating it. Instead of mapping out every possible screen, we identified the key user flows, and created a guided tour of sorts, a limited clickstream that showed as many of the possible UI states, without requiring us to create hundreds or thousands of screens.

As part of this, I started to wonder what stateful prototyping tools would look like. Think about it – using current prototyping tools, if we want to have a collapsable sidebar, we need to make two of every screen, one with the sidebar open, one with it collapsed. Once you start getting more states – say, to use a non-random example, if you’ve got multiple collapsible elements in a sidebar, and some user-configurable data in the main area – the combinatorics make it entirely unfeasible to create a realistic prototype. This… is a thread I’d like to follow up on in the future.

Delivery

And with that, our portion of the project was over. We’d been working up to it for quite a while, yet it still felt very sudden. The last bit to do was handoff, which happened as a Zoom meeting with a couple of the design leaders at Project Jupyter, and a pull request to jupyterlab/design.

Not to be cliche, but this project has been an amazing experience. I’ve learned a lot in doing it, and I absolutely loved working with this team.

Categories
Portfolio

Personas and Journey Maps

Image of part of a persona and a journey map

I mentioned in my post about the research we did that we were working on finalizing a couple deliverables, and that I would eventually post them here. Months later, I’ve finally got the time to do it.

And, before I go any further, credit where it’s due: this was a collaborative work by the whole team:

So, what did we create?

Personas

One of the key tenets of design is you are not your user. Something of a parenthetical on that is that… nobody is The User. Someone is ‘a user,’ but there’s no definitive User out there.

But we’re human, and we need a way to think about the people we’re creating things for, so we develop personas. Create a character who embodies part of your user base – and note, you’re not just making someone up, you’re personifying data you’ve already gathered. (And be sure not to stereotype, while you’re at it!)

Journey Maps

Journey maps fall more into the “UX” than “UI” field. The idea is to follow your user (or rather, one of your personas) through their process of interacting with your design. And, in fact, not just interacting with it, but potentially… not interacting with it. Discovering it for the first time, say, or using a competing product instead.

Once you’ve got the what figured out, get into how they feel as they’re doing it. Is the design meeting their every need and desire, leaving them shouting with joy? Is it completely failing to do something critical, leaving them wondering who in the world could’ve come up with something this terrible?

In short, it’s an expansion of the persona – another tool for getting in the collective head of your user base.

Seeing that linkage, we opted to combine these two deliverables. Take a look:

Personas and Journey MapsDownload

Mood Board

This… isn’t so rigorously researched a design artifact as personas and journey maps should be. In our case, we actually did back it up with some interesting research into the ways that people use and think about organization – I think the key reference would be the Five Hat Racks, although Justin pulled together a lot of research from the early years of computer science as a field, as well. To summarize, there are ~5.5 ways to organize digital files:

  • Amount of use
  • By provenance (source)
  • Chronologically
  • User self-selection/favorites
  • By concept, or by Venn Diagram (thus, .5)

Regardless, the end result makes for a fun visual, so I thought I’d share it here:

A mood board. At center, 'how do you organize?' with five sub-categories, clockwise from top: source, amount of use, concept, chronological, favorites
Categories
Portfolio

JupyterLab File System Research

Sketch of the 'ceilings and bridges' problem - users are trapped below ceilings, and must construct bridges to external file systems.

We’re currently wrapping up the spring quarter, and this seemed like an opportune moment to pause, catch my breath, and go back over some of the work that we’ve done so far.

And I will, first, pause to say that my use of ‘we’ there is very deliberate. I am part of a wonderful team of designers and researchers, working on the file system in JupyterLab:

And myself, in a design role.

After years of being a developer, my first serious involvement in the world of open-source is as a designer. How about that?

So, what have we done so far?

Slide from a heuristic evaluation of JupyterLab, highlighting that the top-level directory is not visible in the file browser.

Heuristic Evaluation

We began with a heuristic evaluation of JupyterLab, going through the process of setting up and using the file browser, and identifying key pain points.

We used Nielsen’s ten heuristics, and assigned a severity rating, from low to high, to problems. And, not to be all negative, we also highlighted some key strengths.

Download PDF
Read on GitHub

Why do a heuristic evaluation?

A heuristic evaluation is a great starting point. It’s a low-cost way to go through an entire interface and identify usability problems, and it’s quick, too.

Working asynchronously, have each of your panel members — and, in this case, the panel consisted of the five of us on the design team — individually go through the interface, making a note of any usability issues they see. Once everyone is done, combine the lists, merging similar/identical items.

Research shows that this technique works, even if the people doing the evaluation aren’t subject matter experts.

Competitive Analysis

Next, we identified several competitors to JupyterLab, direct and indirect, and some influencers — products that aren’t competing with JupyterLab, but could offer some design inspiration.

Download PDF
Read on GitHub

Why do a competitive analysis?

In short, because it’s really helpful to know what your competition is up to. Are there features they have that your users need? That’s a problem. Do you have something cool that your competitors don’t come close to? That’s a marketing opportunity.

It’s a chance to see what the state of the art is, and what market niches are un-filled. (Like, for example, the lack of good sharing features I highlighted in my last competitive analysis.)

Wireframe of a filtering UI in a file browser.

Sketches & Wireframes

While the research team continues with interviews and surveys, Emily and I started in on sketches and wireframes of the new file browser.

See on GitHub

Why sketch/wireframe?

Because it’s too early to be pushing pixels.

Design is an iterative process: research feeds design feeds research feeds design. The initial research gave us our starting point; now, we make sketches, wireframes, and low-fidelity prototypes. The research team will take those and test them. What they learn will feed the next set of prototypes, and the cycle continues.

Especially early on in the process, you want to go low-fidelity; not only because it’s easier, but because it looks easier. If you make something pixel-perfect and beautiful, it looks like a finished project; the people testing it feel bad for pointing out what’s wrong with it, and stay silent, and those flaws work their way into the final product. Nobody’s happy.

What’s next?

We’ve got some more research deliverables that we’re in the process of wrapping up, which I will (eventually) post about here. And then, prototyping and testing!