Iteration 1: Redesigning ScoutApp 21 Nov 2012
One thing I love about holidays is that it acts as permission to totally stop thinking about client work. Once I did that I started thinking a lot about ScoutApp (aka @ScoutForSass).

Tonight I started thinking through two different possible experiences and designs for ScoutApp. I’m going to skip the paper sketches and just share some of the higher fidelity mockups I put together for one of them.

Project Tiles

Project Tiles

The thinking around this project list is to remove unnecessary information while raising the visibility of useful information. arieljake on Github suggested:

an alternate mode for scout that is 100px square with a little circle that goes Green when a compile is in progress, blue when it is “cool” (no changes) and red when an error occurred (and we can click the red light/circle to expand the app).

That idea makes a lot of sense and that influenced this UI:

  • cool blue project tiles are for projects that are being watched but with nothing currently happening
  • green project tiles are for projects that are currently working on something
  • red project tiles are for projects that have reported an error

There may be an orange for projects that report a warning or they may just be treated as red. Still thinking on that at this point.

Interacting with Tiles

  • Clicking on a tile selects it. Not shown in above image is an icon hover over that shows you the explicit state of the tile such as play or pause icons. These icons will be clickable and allow you to start or stop a project.
  • Double-clicking on a tile starts it and moves ScoutApp to a single tile mode. See further below.
  • Right-clicking on tile products a menu that let’s you archive/remove/edit a project.
  • Hitting enter on a selected project does the same as double-clicking.
  • Hitting spacebar on a selected project takes you into editing a project.
  • Arrow keys on the project tiles list allow you to navigate project tiles.

Tile Sorting

All tiles will be sorted by the project name (this will be configurable when you add/edit a project).

Additionally, tiles will be sorted into groups, those that are running and those that are not. The projects that are running will show up first. This way if you have a lot of projects but only care about the one you’re working on it will always appear top left. Easy to spot.

Within each group tiles will be sorted by project name alphabetically (I realize the screen shot above isn’t consistent with this).

Tile Icons

To help make it easier to distinguish between projects an icon can be specified for each tile. This can be any image that you want to use. It will be scaled/sized by ScoutApp to fit the tile and may not fit it perfectly, but that’s okay because it’s just to be a visual cue. This would likely be a logo or some other image you already have in your project, but you can point it at whatever image you want.

The fallback for projects without an icon is to use text as seen in the FOO BAZ tile.

Adding a Project

Right now the plus icon in the sidebar kicks out adding a new project. While I’m not sold on the sidebar or the plus icon (see Issues Not Tackled below) once you interact with ScoutApp to add a new project you’ll be brought here:

New Project, Step 1

On the first page you name the project, tell ScoutApp what the project directory is, and fill out some basic settings. One thing that’s different from the current ScoutApp is that this will store everything in a compass-config.rb file. The most basic options will be presented as a part of this pane, but you can edit the raw config file by clicking on the “TXT” button in the bottom tool bar.

Once you’re happy with settings you click on “Libraries >” to go to the second page of setting up a project:

New Project, Step 2

Libraries is a new concept to ScoutApp which gives you the ability to add whatever compass/sass libraries (aka Rubygems) to your projects that you want to. The only limitation that I think will exist is that it must be compatible with JRuby.

This will be a powerful and important feature to ScoutApp users as it allows them full control and flexibility when they want it, but let’s them ignore it when they don’t.

You may have no noticed there is a lack of icons and that is intentional. I’m not a visual designer and I wanted to lay out the feel of setting up a project first. Expect the text to change at some point to something more visual.

Project Console

The project console is pretty much the same as what exists now except it’s slimmer since ScoutApp is slimmer:

Project Console

The bottom toolbar which allows you to clear the log output is not visible nor are a few other interactions on this page. I haven’t relaly thought about that much yet. I plan to revisit this in the next iteration or two of design.

Project Tile

There’s another feature which goes back to arieljake’s suggestion from earlier: the single project tile.

Project Tile

This mockup shows the three states of the tile, but in reality you’d only see one. It works like this: a user can enter into a single tile mode for ScoutApp.

In this mode they see a single project tile. Again the colors matter: cool blue for running but not active, green for running and active, and red for an error. A user can :

  • single click to see the start/pause icons of a project.
  • double click to be taken back to the main ScoutApp window
  • if the user double clicks on an error it takes them to the console window otherwise back to the list of project tiles

The thinking around this is that you’ll be working on one project at a time and having a single tile mode will be immensely useful. It’d be nice to be able to configure ScoutApp to be able to stay on top of other windows.

I think this is also extendable to multiple running projects. Since a human being is unable to actually work on two things at the exact same time the single tile could simply show the most recently active project w/o requiring you the user to interact with scout again to switch which project should be focused.

Non Visual Things

Thoughts around non visual behavior:

  • auto updates - ScoutApp should at least notify people if there’s a newer version

  • ability to self-update compass/sass (this is a thought not sure how feasible it is if there are dependencies errors)

  • allowing ScoutApp to be connected to by other clients which receive events. This would be so you could have an external client getting notified of everything ScoutApp knows about (projects started, stopped, compiling, errors, etc). Could be cool if you wanted to put up ScoutApp results with custom display.

Issues Not Tackled

I’m not sold on the sidebar and that is why it’s so bare. Currently, it has the plus icon which can be used to add a project, and nothing else. There are a few issues that need to be solved which I’ll try to do in the next design iteration:

  • make it clearer to first time usrs of ScoutApp what to do
  • allow adding a project to be simple, intutive, and quickly accessible.
  • allow archival and unarchival of projects
  • update the damn web-site.

There are also bugs reported against ScoutApp which I haven’t directly addresed. Most of these revolve around a few things:

  • Java installation issues (can’t run JRuby)
  • Adobe AIR not installed (can’t run ScoutApp)
  • issue where numbers where fractional numbers are being converted to 0. This may exist in Compass, Sass, or related to how the file watching gems work with JRuby. It needs to be investigated further.

Iteration One and Done

I was expecting that ScoutApp to have been redesigned several months ago but life happens and people get busy. The good thing is that it’s back as a priority in my sphere of things that need to be made awesome.

So far, I’m happy with the first iteration of design thinking for ScoutApp. There’s a lot left to do, but I’m hopeful.

As I mentioned earlier in this post there is another design which gives it more of a sort of layout. It’s not bad but it doesn’t feel as simple as it should be.

If you have thoughts, feedback, etc, I’m listening, so holla via Twitter (@ScoutForSass, @zachdennis) or post an issue to Github.

blog comments powered by Disqus