The Status Bar Evolved
In the current version of Sifter, the status bar does a great job of communicating and reminding you of the status, but it overwhelms the other significant attributes.
In the current version of Sifter, the status bar does a great job of communicating and reminding you of the status, but it overwhelms the other significant attributes.
There are a handful of "features" that we have strong philosophical objections to. We receive a not insignificant amount of questions about some of these, and I think it helps to explain our thoughts on the decisions that we've made.
Tables are great for purely numerical data. However, when records are a mix of numeric and text data where each column has varying length, significance, and relationships with the other columns, it doesn't make as much sense.
Now that we've been using Sifter in the wild for well over a year in addition to receiving tons of feedback during that time, we've really been able to develop a clearer vision for what Sifter should look like and how it should work. As a result, we've been able to be much more thoughtful about how it all fits together.
The devil is in the details. It's a bit overused and certainly clichéd, but it summarizes a valuable truth when designing. Now that we've sorted through some of our information architecture challenges, I wanted to really look at our new designs and question the value of every pixel to edit the interface down to it's simplest necessary elements.
We're big believers in evolutionary design rather than revolutionary design. With milestones, this became especially true. I briefly shared our thinking behind designing and building milestones into Sifter, and this is a follow up to show how our thinking and the interface have evolved.
We've got a lot of things going on, and while there haven't been any major updates since the visual refresh and OpenID, the next few months should be big.
One of the most common questions and points of confusion about Sifter is comparing it to a help desk. While there is some overlap between help desks and bug tracking, they have some very important differences.
A post to help people who are completely new to search as well as providing a behind the scenes look to some who already have a deep understanding. As a result, parts of this will be very basic, some parts will be fairly technical, and other parts will even talk about some of the interface decisions.
For those of you who use Fluid to create site specific browsers for your web apps, we've finally created a high quality icon for you to use with Sifter. When we set out to create the original icon, we intentionally wanted the style to be something that would work well as a dock icon for a Fluid app, but somewhere along thew ay we forgot to think about the overall shape.
A detailed post explaining a somewhat invisible feature to illustrate the amount of complexity that can be involved in making something "just work".
It's been a while since sharing about how I planned on creating links between issues, and things have progressed quite nicely. Recently, though, I got the idea to add a strikethrough when the target issue has already been closed. I later found out that Trac already does this.
After coming up with a new name and spending some quality time trading ideas with the wonderful Jared Christensen, we've made another big step towards launching the issue tracker. Everybody. Meet Sifter.
Having a clear vision and purpose for your application might seem like just a nice-to-have, but in reality, it's that vision and purpose that determines decisions at every crossroad. Any lack of clarity and strength of purpose will show through in the resulting application.
If there's anything I've learned about designing web applications in recent years, it's the fact that things change over the course of a project. Learning to embrace that fact and direct it towards a productive evolutionary process has made a significant impact on my work.
One of my favorite topics is the influence of business decisions on interface design. It's an unfortunate truth that the underlying business structure and decisions will invariably affect the interface. It's important to recognize this fact and work to improve both simultaneously.
One of the key requirements for creating any kind of issue tracker is making it easy to get data into the system. While the browser is the primary interface, I felt email also had to be a first class citizen for issue submission.
It's not uncommon to spend so much time on the big picture that we overlook the details. While I'm far from a typographical expert, my growing interest in typography has really helped draw my attention into more subtle details that add up to make a difference.
We've taken a look at the concepts behind the issue life-cycle and workflow, and next we're going to see how the dashboard is playing out so far. For me, the dashboard is about quickly assessing the state of projects, and diving right in to managing them.
I've seen countless elaborate ways to link related or duplicate issues. While most of them get the job done, it's generally way more confusing than it needs to be. I considered a lot of different solutions, but in the end, there was one that stood out.
For my issue tracker, I've wanted a more natural process for updating issues. I decided that all activity would have to go through the comment form associated with each issue. This way any change in status, priority, category, or assignee could quickly and easily be associated with a comment.
Last time, I went into my vision of a simpler bug and issue tracking life-cycle. This time, I want to focus on one of the manifestations of a simpler process—the status bar.
Follow the account that's right for you.
We're fast. Ask us and we'll usually get back to you in under an hour.