The "UI Norm" is a broken attempt to reconcile hiding typed characters with being sure it was typed right. It fails this test if the user typos the same way twice.
The method of showing each typed character as it is typed, then changing it to •, allows a single field to provide privacy and be sure each character was typed right.
This looks very similar to http://agilezen.com/ which uses many of the same principles.
I am a user of AgileZen and I really like it.
I like using the board for tasks. Its great to see work laid out like that and as I jump from one thing to another, I can easily move things around. At the end of the day I can clearly see where I'm at.
What are the main differences between the two products? Why should I move to your system from Agilezen ?
flow has some features that AgileZen lacks such as:
* Detailed metrics: You can filter by user, user group, or task type.
* You can go back in time and see how your board looked like anytime in the past.
* Multiple users can be assigned to a task.
* Search everything posted on your board including comments.
To be fair it doesn't look like flow has sub-tasks, custom kanban lanes, or attachments.. all of which AgileZen does have.
I think the biggest difference though is that AgileZen has a very polished and nice looking UI and flow definitely needs some work in that department. You can't underestimate how important that is with an application I am going to be using all day.
flow does support custom lanes. Subtasks are not supported on purpose. They limit the effectiveness of Work In Progress (WIP) limits and reduce visibility. For my take on subtasks, please refer to http://flow.io/finding-the-right-task-size-in-kanban.html
Could you tell me which areas of flow's UI needs work?
I find sub-tasks to be extremely useful, it lets me keep my story cards at the right level for other stakeholders but also lets me add in the detail I need. Without them I end up using some other task list app for the details.
The top bar has 2 lines of text and takes up 20% of the screen. Cards take up a set amount of space so half by board is white space instead of being filled with cards. I don't understand the Calendar or why I would want to see it all the time, if I wanted to see the past state of the board it would be fairly rare (if ever).
Then just the general styling, AgileZen is very polished and clean and flow looks like an app I would have designed. :) (that's why I pay a designer)
I tend to agree with javery. The UI needs polish. Your homepage could use some as well; as it is now there isn't anything that wows me and I wouldn't use this over AgileZen (although I currently do not even use that, the only Kanban system I am using is physical and I use Pivotal Tracker for everything else because it's free and awesome).
UI and design are more important then you think. I don't care about features unless they are so disruptive and innovative that I just have to have them. Saying you have X, Y, & Z isn't really appealing to me. Competitors can easily add features but they can't easily build a better overall experience. Experience is a balance of UI, UX, general design aesthetic, and yes features. The keyword there is balance.
It seems you are currently focused on features and none of the other stuff.
Are you working with a good designer on this project or is it just developers?
I completely agree that features are not everything, and the overall experience is more important. In fact, I don't have any plans to implement subtasks (at least the way AgileZen did it) because I believe they are counterproductive.
The user experience design is mine. Looking at the comments here, I see that some like the design and some not. Interesting divide.
I found it interesting as I am in the market for a decent PM system that follows agile/kanban processes. Here is some feedback:
1. Add the ".io" to your logo. Flow.io is a good enough name, but just seeing "Flow" in the title would make me come back to Flow.com or something.
2. I would very much like to try out using the system before having to sign up and create a name like myproject.flow.io.
3. My go-to PM tool right now is Acunote, and it allows for more free users (5, I think) and 1 project. That gives me the leeway to really use it with a client for a very small project, and then they would start to pay once it grows. At 1 user, that is really only a free trial, and I would not be able to use that with a real client (since we need at least one developer to login and one customer to login). I'm not upset that you're charging, I'm just saying it doesn't provide an in for me to start to use it with people before paying. On the flipside, Acunote is a lot more expensive when you start paying. Also, the flat pricing per user all the way up seems a little iffy, honestly. I think the pricing model should be revisited.
There is a 30-day free trial for paid plans (unlimited users and projects). Do you need a longer trial period?
As for per user pricing, a lot of vendors charge a much higher per user fee (four or five times as much), and they greatly lower their pricing as the number of users increase. I think charging a flat low fee is better because you pay a lot less when you are first starting out. There is also an annual payment option, which gives you two months free.
I'm not familiar with lean and kanban used in this manner, but I would say it is a mis-characterization to invoke Toyota. Toyota's original system was associated with manufacturing, and was quite different from this. Honestly the only cross over I see are the little yellow boxes.
In the "old way", all the parts for a product were made in large runs at one time. It was expensive and time consuming to setup machines for different parts, so better to make them all at once right?
The downside is that you have a pile of inventory to be moved around, stored, kept track of, and the economics of having money tied up in parts inventory is terrible. Not to mention if you make a mistake on all of the parts, you have to throw them all away and make new ones (this happens more than you'd think).
Waste abounds.
With lean manufacturing, the goal was to minimize inventory (waste). The first steps were lowering changeover time on machines, transit time from suppliers, and overall cycle time. You don't need inventory if you can make new parts quickly enough. Not only did it make everything cheaper because there was less inventory, but intangible benefits included catching mistakes earlier and being able to make people accountable. It is a lot easier to call up a supplier and ask what they did differently yesterday to make a bad batch of parts, than to ask them what they did 6 months ago to make a bad batch of parts.
Notice the kanban hasn't come in yet. The kanban is all about information flow. In the old way, someone was making a top down schedule. This assembly line should make this many of these parts on this day, and so on. They had to guess not only efficiency and production time, but demand for the end product. If you suddenly needed extra cars, too bad you had to wait for next year because we have literally no more parts and it takes months to go through the whole dance of making runs of parts again.
In the new way, demand drives everything. The sub-assemblies don't get made until the final production area needs more, the parts don't get made until the sub-assembly area needs more, etc. The information flow is not top down, but basically bottom up or end back.
The kanban helps with that, basically the kanban is a note from people downstream saying we need more of what you make! Make it!
A simple example. Imagine a factory that makes syringes (not morbid, just simply one factory that showed me their implementation of lean manufacturing/kanban). You have one room making plastic parts and one room making metal needels, one room assembling the parts, and one room shipping them. Roughly 25 machines involved, 20 people, and a few million needles a day.
The shipping people get orders, and grab boxes from a small inventory, maybe there are 3 pallets of needles kept there and when they get down to 1, they grab a kanban and walk it back to the assembly area. The kanban is a simple magnet.
When the assembly people get a kanban, they place it on the appropriate machine and pull baskets of parts off the wall. They might have 5 baskets of plungers, 10 of bodies, etc. When they get down to a predetermined number they walk a kanban back to the plastic extrusion room and slap it onto a machine.
The guys in that room start making the appropriate part and filling up bins. They might have 200 or 300 kanbans in the factory that are just little magnets telling people what to do today.
There are no more schedules or even management telling people what they should be doing, the people on the floor are doing that in real time as orders dictate. It is simple, elegant, and works amazingly well.
However, I don't really see the connection to project management or software development. Someone please enlighten me (not being sarcastic, I just really don't get it). I push lean and kanban in manufacturing all the time - I'm a huge believer - but I would love to extend it into engineering/design if someone knew a way.
Thank you for the detailed explanation of how kanban in manufacturing works. Here is how it works in knowledge work:
kanban is a pull system. You pull work only when there is capacity to handle it. This works well in a factory setting because you know exactly how much capacity you have. In knowledge work, however, it is likely that you do not really know what your team is capable of because:
- Knowledge work is invisible and highly variable.
- Most of the time everyone is working on everything.
- There is a hidden but significant cost of task switching caused by multitasking.
If you want to know your team's capacity, you have to limit the number of tasks they work on at the same time. This is called a Work In Progress (WIP) limit in kanban. Once you limit WIP, several interesting things will happen:
- A backlog of tasks will emerge.
- You will be able to measure how much time is spent on each task.
- Tasks will get finished faster.
The first two results are not very surprising because by introducing WIP limits, you have effectively eliminated multitasking, but how on earth, do tasks get finished faster?
- Unlike computers with multiple processor cores, our brains have one or at best two cores. Without WIP limits, when there are too many tasks to work on, we spend more time on switching tasks than the tasks themselves.
- Bottlenecks become visible. Since everyone is working on a limited number of tasks, some finish theirs on time, some get overloaded, and some cannot finish their work because they need input from those who are overloaded.
- Team members with free capacity can help those who are overloaded. Better yet, they can even come up with ideas on how to fix the newly discovered bottlenecks.
I've never heard of kanban. I'd make it more clear on the front page that it's a system developed by Toyota (I had to click the kanban link at the bottom of the page to learn that).
Knowing it's something to do with Toyota peaked my interest but having to click to another page lost my interest.
EDIT: In addition, it wasn't clear to me that the tabs at the top show more information. I assumed they would ask me to login so at first I didn't click them.
Really good page. Interesting and beautiful.
I'll be using it to see if this model is right for me.
As a good surprise, I discovered the Midori framework you use behind the scenes. In addition to be lightweight, I like it how you use it in flow.io, So I'll be playing with it as well.
http://www.midorijs.com/
I've never heard of kanban but I'm sold so far. If your target is people like me I would probably try to summarize a bit better just what it is on your first page (I'm guessing this is not the case).
Three things caught my eye. I don't like not being able to rename "backlog" and "done", the former more than the latter.
I don't like the "What's New" opening on the same page as my board. I'm not sure what the etiquette is these days but I would much rather it open in a new window (read tab) so it would not interrupt my usage.
And lastly, as rmc mentioned only one password box - why not have two?
I do like how everything is nice, simple and clean. Good job. I'm going to use this on a project I've been trying to finish for months.
One edit after more usage. The linked text on the "post it" extends all the way to the end of the line causing me to follow a link when I want to move an item. Is this a bug or a limitation?
I'm not familiar with kanban, other than by name. Site is visually appealing, but I'd suggest reworking the design to use a portion of the empty space on top of many of the pages.
I owned this domain for awhile, glad to see someone from HN using it now.
Glad you liked it! The demand for kanban is not high at the moment, but this is because kanban for project management is a very new concept.
I believe flow.io solves a number of painful project management problems such as extensive upfront planning, making accurate estimates and manual time-tracking. So, word-of-mouth should be enough to find customers in the beginning.
It's funny, I wrote a Kanban board to my ex-employer and know other people who work on similar projects. New competitors pop out every week. Way too many Kanban boards already.
Really opens the mind on how to use one. I showed this to our development team today and one of them said 'Surely you could just make this into a computer program?'.
The reason I think this doesn't work as well as a computer program (and take this as feedback to your project), is as following:
- Having a physical board on a wall is visible to the team, all of the time. A computer system has to be checked, it has to be opened or at least brought to the front of your windows to think 'What am I supposed to be doing? What is there to be done'. Having a real physical board in your office allows you to easily get distracted and get back on track.
- The other advantage of this, is that it is seen by everyone in every department. I've worked in places where support teams use one internal system and development use another and despite being linked are often only viewed internally in department. Although this works fine, by having a physical Kanban board on your wall, it is visible by everyone in your company all the time! Everyone will know what people in their department and outside will be up to ... this helps manage work load for people and stops people having to constantly ask 'what's happening with A or B?'. It also stops people ignoring difficult tasks, or urgent bugs - as everyone knows it's there and needs to be done asap.
- Having a real board that you stick post it notes on is quite a fun task to do. Especially looking at the added fun from the slides (e.g. little character people and cartoons).
- Having a real hand drawn board is flexible, you can change the way you use it depending on how your company is run / departments are set up.
However,
There are many disadvantages of having a hand drawn one which a computerised one would improve. The key and biggest off the top of my mind is integrating with existing source control / project management solutions.
e.g. TFS has a work item number. If you have a hand drawn board with a post it note with the TFS number in the corner, you'd still have to look up what that item is in TFS. Where as in a computerised system you can easily access that information perhaps from clicking the work item.
However, all this said, I still think you've made a good start and have a nice product. Your best bet would be to approach different real development teams early and see how they would use it and what pain / gains can be made.
- Visibility and fun are key deal breakers here. If something is a chore, boring or painful - then people won't want to do it. Make it fun and they'll happily do it and it adds motivation to the team moral!
sorry, if i had one i prolly would have said. don't take it too personally - i just hate the buzzwords and feel obliged to make my statements in this way.
i've always seen project management and lean as variations on common sense and kanban i've never really looked at to know what it is because i've prejudged the whole field it belongs to as a redundant - or for those too lazy to engage their brains.
if forced maybe "Effective, common sense management"? the whole "project" "specialisation" has always seemed redundant to me...
then again buzzwords do sell. so don't listen to me if you want to sell. the masses of businesses are what matter and they are generally the sort to buy things because of buzzwords rather than demonstrable results. :)
I think the gradient at the top of the page is horrible. The rest of your design doesn't have gradients, I don't think you're well served by them.
Since your tabs are your primary navigation through the page, they should be a lot bigger.
The call to action should be much more centrally placed, and closer to the point where people finish reading (ie, lower). It should not be a green button on a greenish background.
