Anteater Design Part I
Ok, first post exclusively on Anteater, leeeeeets goooo!!!
First off, I’m no designer. There are so many examples of beautiful web design out there, and this will not be one of them. Anteater’s visuals, like the little guy above, might have more of a creepy, crawling-from-behind-the-couch kind of appeal. That being said, I’m getting better.
So what’s Anteater? “Anteater is a common name for the four extant mammal species of the…” Wait, wait, no. Not that kind of anteater! (although they’re awesome too and you can continue reading that quote and more about them on wikipedia). My next coding project is titled Anteater. It’s a simple bug tracking tool where users can identify, track, and resolve bugs in their projects. If you want to learn more about how I decided to build this project, you can check out my blog post on that, here.
In all my previous projects, my teams and I designed our apps for a standard laptop screen first. The projects went well, but adding responsiveness at the end of the project and trying to cram Geocoder maps and search fields onto a mobile screen was a pain. Looking into how to do it better, I found mobile-first design. The idea behind mobile-first design is that you are doing the hardest work first. On a phone, you have limited screen real estate, so you need to display only the most critical information, while still giving the user a positive experience. There are also little quirks to keep in mind such as being unable to rely on a mouse hover to indicate interactivity.
I started by writing down all of my user stories on a Trello board:
I ended up with 25 user stories, including “bonus” features I wanted to implement such as signing in through Facebook and Google and having email invitations sent to potential new users. For starting, this is a lot. 25 stories to be usable on mobile for a practice project. I had enough of a challenge ahead, so Facebook, Google, emailing, and few others had to go.
(And as a note for adding features because they would be cool: As I’m learning, I want to be exposed to a lot and try new things, but at a certain point there might be a diminishing return if I go way past the point of a minimum viable product. So for now, I’m going to keep the app simple and double down on the skills I want to practice and learn.) Anyway…
I started taking notes and drawing out sample designs:
Since this project’s goal is to practice Rails and learn React, I decided to speed up the process and do what I assume many great designers do. I copied.
I took inspiration from a couple different mobile templates:
And I found a bug tracking app to copy from as well, which was a great way to help think about the layout of the information and the user experience:
Disclaimer: In regards to copying, if it wasn’t clear, Anteater is entirely for practice and not for commercial use.
Now for the designing!
I opened Figma and started to make lots of mobile pages. Starting with the landing page:
The grey circle is where the logo will go. With many of these pages I have grey circle placeholders. Also, going forward, much of the text doesn’t have a set font or the correct font size. I focused on the layout to make sure I was able to get all the critical content displayed for the user, and for that some of the style was cut short or skipped. I also did not include some pages such as the login or sign up pages because I assume I will need to finagle with the pre-made views after setting up the app with devise.
So let me walk you through the app!
Here we have the home screen that can take you to All Bugs to see all the bugs assigned to you and those you reported. There are Projects, where you can see all projects of which you are a member. There’s Add Bug, to, well, add a bug, and Account to edit your details. In the dropdown there is Blog which leads to this blog so anyone can review how I created the app. And lastly, there’s a magnifying glass at the top that leads to a Search Bugs function.
Let’s check out Your Bugs and Search Bugs:
In Your Bugs, you can see all bugs assigned to you and bugs you reported. The big plus symbol leads you to the Add Bug page. The 5 fields under the h1 “Your Bugs” can filter the list by project, severity, date, status, and the bug’s relation to you. This is one area of the app I have to criticize myself. I think this is a clunky, busy page. I tried using less fields, but it made the page feel less useful. Perhaps when learning react to implement the front end I will find a more elegant solution.
In Search Bugs, you can search through all bugs reported in any of your projects. It will search all fields in the database for each bug based on the word(s) you search. This can be users, project names, description, etc…
Then when you click on a bug:
On the show page for an individual bug, you can see all the details for an individual bug. If you want to edit the bug, it will allow you to edit all fields except who reported the bug and the duration, which tracks the reported date to the current open date or the date it was closed. Note- the only people able to edit a bug are the person who reported the bug, the person assigned the bug, and the admins. (Or at least I think that is a good way to keep the authorization for now).
For adding a bug, I did not create a page. I think I will build that form based on the rest of the design as the app comes together with React. It should be a straightforward form with a submit button.
Tired of bugs yet??
Ok then, move on to projects:
When you first click into projects, you will see all of your projects listed with the name, description, number of open bugs, and number of critical bugs. You can sort by whether if you are the admin, not the admin, or either. This might switch to simple analog buttons/tabs. The app will automatically sort projects by number of critical bugs as a secondary search parameter. I assume no user would have so many projects that having less search functions would be a problem. Additional search parameters could always be included later.
When you click into a project, it brings you to a page very similar to the home page. It allows you to go into project Bugs, project Users, project Reports, (Which is not yet designed, but will include stats on average open time for bugs for the team and individual users, number of total closed bugs, and bug status ratio (ex: 10% unassigned, 30% open, 60% need to be tested)), and project Settings.
Project Bugs is very similar to the original Your Bugs page, but now you can see all bugs reported for this project in particular. Navigating to Add Bug from this page will automatically fill the Project field, with the name of this project.
Settings:
Project settings is a bit more bare bones. The only information displayed is the name and description. The edit button (for admins only), takes you to another form to edit the original info as well as an option to delete the entire project and all bugs related to the project. Lastly in settings, there is option leave the project.
Now for users:
The users page indexes all users connected to the project. In the user page you can sort by role or alphabetically. Clicking on a user extends their card to show more details and give options to change the role between admin and normal user, and also an option to remove the user from the project. Only admins have this option. A normal user that looks at this list and clicks on themselves will have an option to leave the project, but no other options will be available. An alert will pop up for any of these changes.
And what about the big plus button?
You can add a user by searching all registered users by username. All matches will have an Add to Project button. This button expands the card with an option to set them as admin or normal and then a save/add option. Another alert with show up after this action.
This page is another criticism I have of the project. New project members need to already be registered to the site and the admin need to know user’s username to find and add them to the project, and there’s no alternative. It would be better with a link to send to others so they can join/edit, or an email system so you can input your coworker’s email and have an email sent directly to them inviting them to join. It would be a better user experience, but perhaps the last priority among everything else I want to accomplish with the app.
So that’s Anteater’s mobile design! It could be better, but it gets the job done. All core functionality is there. On the desktop, looking through bugs will be much easier and more detailed since more space will mean better tables for displaying the bugs. This is why it is a good idea to design the mobile side of an app first. Taking away content and trying to design smaller would be a huge headache. And now I fully grasp the app’s functionality and it’s purpose.
Then again, this is all in the design stage… Learning React and how to combine some of these smaller pages as the views get larger is going to make things quite different, I’m sure 😅
Thanks for getting to the end of this longer post. Here, have a cute anteater gif!
