Navigation
Learnability: how rapidly and easily can users understand how to operate the interface?
- In terms of learnability, the interface offers a consistent navigation bar on the left hand side that allows the user to immediately the three major uses for Fritter: their home, profile, and nests. However, confusion can stem from distinguishing “profile” and “home,” so I might edit the navigation bar to list “feed,” “profile,” and “nests.”
- There’s a slight tradeoff between maintaining the same language in Fritter and other social media apps. Currently, my Fritter app uses quirkier descriptions of basic concepts, i.e. calling posts “chirps,” calling friends “chirpers,” and calling circles “nests.” This can create a bit of friction for a user just learning to use the platform, but also is a refreshing difference between Fritter and other social media apps. In this case, I’ll keep the different language on Fritter, trading off a bit of friction in terms of learnability.
- On my interface, a user has the ability to set when other’s users posts will be viewable on their feed given the author’s nest. However, I believe my interface does not necessarily convey this idea clearly. To improve, I think I’ll expand the language on the times page to say “Nest viewable on feed from …” to convey the idea that the times set on nests affect the posts a user sees on their feed.
- I believe to make it clear that an author can post to only certain nests (i.e. make a post visible to only the members of a nest), when posting, I’ll change the language from “Nests” to “nests that can view your post.”
Efficiency: once you know how to use an interface, can you use it to quickly and efficiently accomplish your goals?
- In terms of posting, a user can always have the opportunity to post on the top of their feed page while scrolling on other posts. While viewing another user’s profile, they can easily see what nests they belong to. To reinforce this idea, a user can also view what nest another user is part of by viewing that user’s posts on their feed. It is also easy for a user to see which of their posts are viewable to members of a certain nest by going to their profile and seeing which posts belong to which nests. Although I’d like to have a quick “add/remove to nest” on other user’s profiles, I would have had to tie user objects with nests, which would have de-modularized the backend.
- To make the interface more efficient, I could implement a series of keyboard shortcuts so the user can perform basic actions much quicker, such as
cmd + n to represent creating a new nest. However, it would be difficult to learn about these keyboard shortcuts, and would require an additional page in my app to describe all the new keyboard shortcuts. However, if possible, I believe this tradeoff should be useful for experienced users and can add cool efficiency benefits.
Perceptual fusion: how does the interface account for time delays?
- In terms of time delays for loading on an infinite scroll, my interface will let the user know when they’ve reached the end of a list of items, such as nests, posts, or friends.
- Otherwise, my interface currently does not take into account the user experience. Therefore, I’ll need to design some loading screens and confirmation messages to help provide the user with feedback that will provide them a more comfortable user experience. I’ll also need to account for error messages to help the user understand the difference between a time delay and an improper action.
Situational context: how does the interface convey to a user their context (where they are, the app’s state, etc.), and how does it adapt to their context?
- Currently, my interface has three major states: feed, profile, and nests. To help the user contextualize where they are in the app, the navigation bar on the left highlights where a user is in the app, given their current position. My interface also provides the name of where they are on the top of the page. In addition, when clicking on an item that will take them to a different page, my interface provides an information “crumb” to allow the user to visualize there they would return to if they clicked the back arrow icon.
- In terms of the feed’s state, my interface highlights with a underline which nest filter a user is applying to their feed. In addition, if a user tries to filter by a nest who’s time is not within the current time, it provides a cute error message: “nest is asleep.”
Consistency: does the interface reuse the same names, symbols, and icons for the same concepts or actions? how consistent is the interface with others across the same application domain or platform?
- Within similar applications, such as social media, Fritter uses different names for popular concepts (such as calling friends “chirpers”). Although it creates a lack of consistency across applications within the same domain, it allows for a new kind of internal consistency: given that Fritter’s logo is a bird, by relating popular concepts to bird-like names, a user can create a new, unique kind of concept model based on their understanding of chirps, chirpers, and nests. For example, given a nest usually holds other birds, it makes sense for a user to group other chirpers in nests, and as a chirper, to “chirp” to their different nests. However, I did find in my wireframes places where chirpers are called friends, so I’ll need to go back and make sure I’m using the same language throughout my entire app.
- Within similar applications, such as social media, Fritter uses similar icons to reinforce what different concepts are to a user. For example, a user can “add” something with the suggestion of a button that contains a
+ sign, and edit a nest’s time by clicking the clock icon. In addition, to ease some of the friction of not being consistent with the same language as other social media apps, Fritter uses grouped user icons to represent groups of users such as mutual friends, or nests. However, in order to separate the suggested friends concept from mutual friends, Fritter uses a world/globe icon as a way to hint to the user to “explore” the suggested friends as well as reinforce the difference between these two concepts.
- Given the bulleted point above, I believe there might be some confusion between reusing the grouped users icon for both nests and mutual users. Therefore, I’ll change the nests icon to be the grouped users icon in a nest, which should hopefully reinforce the idea that users are grouped into a nest.
Recognition vs. recall: does the interface force a user to remember operations?
- Currently, the interface does require the user to remember that in order to set a nest’s time, they have to go to their “nests” page as well as a nest’s actual time, since you have to click on the clock icon to see the start and end time of a nest. In terms of the first point, to make it clearer, I’ll make times a separate link the nav bar. In terms of the second point, given this is actually quite a lot of information to recall and would force the user to click on each clock icon to see the times for all the nests, I think it makes sense to eliminate entirely the clock icon, and instead allow the user directly just see and edit the start and end times for a nest.
- A tradeoff is that the interface also forces the user to remember that in order to see another user’s suggested friends, they must be friends with the user. Therefore, I’ll make suggested friends public instead so that it’s easier for other users to find each other.
Application
Repo