Beta: Open Issues of Note

Summary: From the Editors: This is Curt's list of what he feels are meaningful usability issues that we know about in the Beta.

From the Editors: This is Curt's list of what he feels are meaningful usability issues that we know about in the Beta.

The problem with creating software of this scale is choosing the balance between the minimum features necessary to go to market (in enterprise software - a lot), and the desire to get software into the hands of customers who will validate or invalidate your assumptions.

• It's not obvious when a parent hierarchy is limiting a task's workflow choices. We do not show blocking ancestry. (necessary) Likewise it's not always clear why you can't do something when you don't have permissions to - we don't give the user enough feedback when he lacks permissions to do something (mostly, change state).
• Changing a parent is not cascading state changes to children. This was originally by design and we must change it. (necessary)
• Changes to the gantt view are not cascading - tasks are not 'floating to the soonest time'. This is a simple issue, but has performance consequences we must naturally pay in a simultaneous multi-user system. Wrapping and testing this kind of transaction is an issue we kept postponing in favor of feature complete, and now it's bitten us. (necessary).
• You cannot log in two different users with the same browser. We originally did this by design but feel it was a mistake because of our over-concern for security. (nice to have)
• There are still areas of the app that are not being updated dynamically via websockets. This was a decision we made in order to get to v1 feature complete. Most of it the user will not notice. The most common issue is on single page views and tabs. The workspace tends to update just fine. (necessary)
• There is still a problem with the chat not echoing what you're posting even if it's being broadcast. Likewise websockets are not always aware that they've lost connection overnight and the browser requires a refresh. (necessary)
• We have not Less-ified the CSS, nor optimized the CSS or the Div structure. We considered this a high cost, that was best paid for prior to release. Why? It's plenty fast, and works just fine. Feature complete was our goal. (nice to have)
• Closing and re-opening the same sliding page causes some sort of delay because the last fetch was incomplete. (unpleasant);
• We postponed Drag and Drop to Tag on the Board view. (urgent) We had too much debate over this issue so we postponed it until we had feedback. IMHO we fell into the methodology trap instead of just leaving it up to the user. This illustrates the fact that as we evolved Runcible we 'subtracted methodology' in favor of user centricity.
• We postponed the control panel for managing the different periods, and without it, managing your entire business's operations with Runcible isn't as intuitive as it should be. (nice to have). Our thinking was that during the beta period no one would likely use it, and it would have to be the very last feature we built - despite being one of the first we designed..