Can anyone help me create a User Story for the dragging and dropping feature, where I can drag and drop projects from "New Project" to "In progress" etc Column
User-stories describes a feature from the user's point of view, making clear what the user wants to achieve. We cannot invent stories for your users: normally, you should discuss this with your users. But if you're learning and it could help, here an hypothetical example:
As a project manager I can drag a project icon in the "new project" column across my kanban board and drop it on the "in progress" column, so that I can easily and intuitively communicate that a project was started and is still going on.
Be aware that referring explicitly to a drag and drop seems very detailed and might not leave much room to propose better solutions. In this regard, you need to keep in mind that a story is not a detailed specification. It's just a placeholder for a conversation. Personally, I'd rather go for something simpler like:
As a project manager I can easily chose a project to launch and show that it is currently in-progress, so that the other users know on which project they may work.
I would then discuss with the user about the details of the story. Maybe drag and drop is the way to go. Maybe keyboard control (tab to select, space to chose target) is needed for accessibility reasons. But perhaps I'll discover that some users prefer to update the status in the project card if it's on the screen.
Anyhow, during this conversation you'd write down all the expectations, positive and negative, for the acceptance criteria. For example:
Dragging from "new" and dropping on "new" cancels the drag&drop operation
When dragging from "new" a visual feedback should be given to show the project moving
During the dragging, the use of the escape button may cancel the operation.
When the project is dropped by accident, the user may undo the operation.
When the project is successfully dropped on the "in progress" column, any open view of the project card should be immediately opened to show the new status of the project.
Attempting to drag a project, of which the user is not responsible, should lead to an error message about missing authorisations, etc.. .
Related
Is it possible to automatically have the state of a work item be changed to something appropriate like "Active" when dragging it from your available workitems to the in progress work-field?
It would save the work of manually opening the workitems whenever you start working on them, just to set the status, and then adding them to the "in progress work" anyways.
EDIT
I am talking about the visual studio tfs explorer! thanks for editing my post so that it doesn't reflect that anymore! (sarcasm)
You didn't specify so I'm going to make some assumptions. I'll assume you're using TFS 2013 and the Scrum Process Template. I'm not sure if you're talking about dragging items around on the Kanban board, or the Task Board. The way you configure each of those boards is different.
For the Kanban board you can map columns to WI states using the built in UI. Just click Customize columns, then you have the name of the columns at the top, and the WI state they map to at the bottom:
For the Task Board you need to use the witadmin.exe command-line tool, you execute witadmin exportprocessconfig, modify the xml file, then do a witadmin importprocessconfig to upload the changes. The relevant section you need to change is the TaskBacklog section which maps taskboard columns to WI states:
Is there a way in MKS Integrity to clean up the member view? We have files that when you open the Member History view just look like massive spider webs. It would be nice if we could click a revision, hit a magic button, and only see the revisions directly tied to that revision (i.e., one level out from it). Does anything like that exist in MKS? (obvious: I'm new to MKS)
From the Member History window, go to menu -> View -> Change Filter to bring up the Filter Revisions dialog.
Modify the Filter Revisions based on whatever criteria you care about--in this case, probably based On Branch.
Click OK.
The member history should now display a filtered member history.
Unfortunately, there is no functionality for a "single button filter by current branch". If your organization has a current maintenance contract with PTC, you could have an appropriate contact log a feature request for this functionality on usability grounds.
Disclaimer: I work in PTC Technical Support.
As far as I know all my colleagues have the same problem. I can only give you the hint that when you have the Member History window you can set a filter in the menu [View].
Better would be to have some right-click menu for that - but this might be something related to an external script?
If you are using dynamic Member History views you might also consider having always 2 dynamic Member History views open.
One as list that shows all.
One graphical with a filter enabled with View -> Change Filter
If you never close that graphical history view the filter will remain active
even if you restart the Integrity client.
In Xcode 4 (4.2), is there a way to keep the Project Navigator view open and Debug Navigator view open as well. Must a user have one or the other, but not both? And the other navigators?
Apple seems to have decided that if you want to see the debug view, you don't want to see the files in your project. WTH? Am I getting this wrong? Did Apple Xcode UI guys even talk to developers before designing the UI for Xcode 4?
Sigh...
You can indeed have more navigators open at once, if you are prepared to have multiple windows open. I know it's not exactly what you're asking for, but for multiple display setups it's very handy. Xcode provides "behaviors" to help automate this process if you only want certain things showing at certain times.
For example, a common pattern that developers follow is to setup a behavior for "Run starts" that opens up a new window setup for debugging. Start by creating a new tab in your main Xcode window by pressing command-T, and double-click on the tab's title to rename is "Debug", or whatever you like. Then drag that window out (or leave it as a tab if you like), and customise the view as required - for example, for a deb window you might have the Debug area showing at the bottom (or even covering the whole editor view), and remove the toolbar at the top by right clicking and selecting "Hide Toolbar".
Next, go to "Xcode > Behaviors > Edit Behaviors..." and choose "Run starts" in the left panel. Check the box for "Show tab" and enter the name of your newly created tab. You can also ask that tab to automatically show the Debug Navigator, and show the debugger with variables and/or console view. If you like, you can then choose "Run completes" and show the original "tab" (window), which I've setup to be called "Coding", and show the required navigator (in my case, Project Navigator).
On successfully running, Xcode will now open up your new window (or bring it to the front if it's already open) with all the settings you left it with. On stopping, your main editor will be brought back to the front.
There are loads of useful behaviors, so I would really recommend looking through them and taking the time to setup Xcode to suit your style as best as possible. All software dictates to the user how to go about doing things, and the developers can never please everybody when they decide to change the UI. The best anybody can hope to achieve is to customise the interface as best as they can to fit their style of working. If it's still an issue for you, you can either adapt to it, or, if possible, move to something else.
I'm not a fan of every new interface feature in Xcode, but I've "made it mine" with some customisations and I can still be very productive. That being said there are a lot of things that I do really like about it, and for that I can forgive it for some of the less friendly features - after all, you can't please every user.
I'd like to know if it ever makes sense to provide some functionality in a piece of software that is only available to the user through a context (right click) menu. It seems that in most software I've worked with the right click menu is always used as a quick way to get to features that are otherwise available from other buttons or menus.
Below is a screen shot of the UI I'm developing. The tree view on the right shows the user's library of catalogs. Users can create new catalogs, or add and remove existing catalogs to and from their library. Catalogs in their library can then be opened or closed, or set to read-only.
The screen shot shows the context menu I've created for the browser. Some commands can be executed independently from any specific catalog (New, Add). Yet the other commands must be applied to a specifically selected catalog (Close, Open, Remove, ReadOnly, Refresh, Clean UP, Rename).
Currently the "Catalog" menu at the top of the window looks identical to this context menu. Yet I think this may be confusing to the users as the tree view which shows the currently selected catalog may not always be visible. The user may have switched to the Search or Filters tab, or the left pane may be hidden entirely.
However, I'm hesitant to change the UI so that the commands that depends on a specifically selected catalog are only available through the context menu.
The Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista states (pg233):
“Don’t make commands only available through context menus. Like shortcut keys, context menus are alternative means of performing commands and choosing options.”
The Apple Human Interface Guidelines states (pg189):
“Always ensure that contextual menu items are also available as [pulldown] menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command.”
In your case, opening and closing the catalogue appears already available through the +/- buttons in the tree itself, so you’re already consistent with the Windows guidelines, if not the Apple guidelines. IMO, the only reason to put them on the context menu at all is if they're the default (double-click) action (which they're not right now). Rename may also already be available by directly selecting the name of a selected catalog, but you may want a pulldown menu item for that any way since that may be no more discoverable than the context menu. The rest of the commands probably belong on a pulldown menu in addition to the context menu.
As far as the Catalog pulldown menu being redundant with the Catalog context menu, you may want to consider organizing your pulldown menus by type of action, rather than class of object, in order to provide an alternative organization. As you’ve realized, context menus already organize commands by class of object. In addition to providing an alternative organization that some of you users may find more intuitive, this may simplify your menubar. For example, rather than a Catalog and Family menus, you can have a single Edit menu with Add, Delete, Rename, Copy, etc. where these commands apply to whatever is selected, whether it be a catalog, folder, or family. If they don't apply to the current selection, they're disabled, but if it makes any sense in your app, make them apply.
BTW, what’s the difference between Add Catalog and New Catalog?
In general, it's a bad idea to have menu items accessible only through a contextual menu. Many users may not think to right click on an item to find out what actions can be performed on an item.
From your description, it sounds like it would make sense to have a 'Catalog' menu that disables menu options that are not currently relevant. For example, if no catalog is open, the 'Close' menu item would be greyed out. Similarly, the 'Open', 'Remove', 'Refresh', etc. items would be greyed out if no catalog is selected.
I suppose this depends on your user base, and who you're targetting your software at. Personally I wouldn't expect the user to be able to deduce what functionality is available when it is essentially "hidden" until they right-click on the correct item.
If it were me, I'd have a toolbar shown with the functionality exposed on there. By default the buttons would be disabled, and clicking on a node would enable the appropriate buttons based on the context. You could have this in addition to your current right-click options.
As a rule, I've always treated right-click menus as a redundant (i.e not necessary for operation of the software) shortcut to functionality for "power users".
I would leave the menu item out because the user doesn't have a way to see what catalog they are modifying if the treeview is hidden which can create problems if they think a different one is being shown.
Though, the accessible solution would be to trigger it with the keyboard also.
Yes. One key feature of UI is "discoverability": can the user find the function?
If you think that having a top-level menu doesn't make sense, based on the context, then you could have a menu button (scroll down) labelled (e.g.) "Actions" at the top of the pane.
My application is context-sensisitve and I dynamically build menus for the main window / context/popup, and other places. I typically know if a given menu command will be valid given the current state of the application. Is it better practice to DISABLE/GREY the menu options which currently do not apply OR since I'm generating the menu anyway, OMIT them entirely?
The application is a Java/Swing is anyone is curious. The question seems GUI toolkit agnostic but may be platform dependent.
The old apple guidelines say to Disable for fixed menus (in the menu bar), and omit for context menus.
I guess the motivation is that a context menu is supposed to only show options that are available to the particular context, and the main menus are supposed to show all commands, so the user knows where "Save" would be even if it's not selectable at the moment.
For right-click menus, I'd say that if the item is applicable to what was right-clicked but is for some other outside reason unavailable, disable it. If it is not applicable to the right-clicked thing then hide it as there's no chance of it ever showing up. Case in point:
When I right-click on the background area of this page in Firefox the first four items are Back, Forward, Reload, and Stop. Forward and Stop are disabled because they aren't valid actions right now (I have no forward history and the page is not loading anymore). These four guys are very consistently offered, they are expected, global, often-used commands. They are the four main "navigation" controls and by default they have toolbar counterparts (in the form of big dedicated buttons).
However, if I right-click on an image, I get completely different options in the context-menu all related to viewing, saving, and copying the image under where I clicked. These options don't appear at all (not even disabled) under normal use because they are very specific to what I right-clicked on. When right-clicking on the background area, Stop and Forward, while currently not valid actions, are still applicable to what I clicked on (the page) but they are unavailable for other reasons...
Like the rule for menus on the top menu bar, the goal is not to surprise users with commands suddenly appearing for, from the user's point of view, inexplicable reasons.