Dine kommentarer
Ok, I'll add the feature into our backlog without remembering the state of collapse for now, and see how that works from a user experience perspective. I am worried actually that if we stored the collapsed state, we could confuse users who don't realise the theme is collapsed anyway, so this would avoid that problem.
13 år siden
We can understand the value of this, but we are actually trying to simplify the interface at present, and we are concerned that adding more icons will in fact complicate things. Let us have a think about how, and if, we can accomodate this feature. We'll update this ticket when this feature along with the other GUI improvements are in the current sprint.
Nice idea!
We're thinking of ways to improve the way we present the theme and story tools to users, so when we re-look at that we will definitely consider adding a feature to expand/collapse themes.
BTW. One quick question - do you think it would be useful for the app to remember which themes are collapsed? I am not entirely convinced it would be a good idea as it could be confusing for users, but am interested to hear what you think. Also, I assume if a theme is collapsed and you are tabbing forwards or backwards, we should simply skip over all the collapsed stories.
Hi Michael, interesting idea. We actually spent quite a lot of time getting this to work as it does where the current assigned stories never scroll off the page and you can scroll one page rather than two separate areas. I must admit, I'm not entirely convinced having separate scrolling is the best from a usability perspective, I see the advantage when assigning stories, but it also introduces complexity having two different scroll bars. If it's OK, I'm going to park this idea and see if others also find the current format problematic? If you feel strongly however, do drop me another line and I will review again.
Ok, good idea, that's not a big feature to add, I'll look into including that in a future release.
Hi Michael
We do currently show when someone else is editing the same backlog, a pop up appears in the bottom left telling you who has edited the backlog. Doing auto-update in AJAX is possible, but I am not sure the effort versus the reward is in fact worth it when our customers have told us that concurrency is actually quite rate at this stage. If this changes, we would consider realtime updates but that would introduce some problems.
Is the notification that is currently shown not sufficient, or do you think we need to tell a user when the backlog has actually been changed?
Ok, thanks for clearing that up. I think it's back to the drawing board for us in terms of how we do user management, which is now admittedly a bigger task, but one that we need to get right. I will work on a solution, but unfortunately based on the current backlog, I don't see us being able to address this one until Feb now :(
Thanks for the reply Michael.
What we have planned is to add the ability to add users with read/write access, but only on either an account level, or on a company level. The few people we have spoken to have said that normally they only need granular access to the level of company. Do you use the company feature and assign backlogs by company? Would that level be sufficient, or do you really need it down to backlog level.
The only reason we are reluctant to do permissions at a backlog level is that it just complicates the interface a bit more, and we're trying to keep things as simple as possible.
Thanks
Matt
Matt
Kundesupport af UserEcho
