Is there a way to reference page numbers in PowerPoint, the way one can do in Word? For example, I'd like to be able to write "details on page 10" and to have the number 10 updated automatically if the page number changes because I have added or removed other slides.
No, afraid not, at least not out of the box, though one might be able to write an add-in that updated everything when the user clicks a button or (with more effort) automatically when they add/remove a slide.
Related
I'm trying to have a feature to allow users choose two different methods of cost calculation: either they can enter a yearly cost breakdown on a datasheet (2010: $10,000, 2011: $12,000, etc) or they can enter a flat yearly cost multiplied by the number of years they select.
If I were developing another kind of web application, I'd have radio buttons to select two different options. One option would display the datasheet, and the other option would display two text fields to enter values into. However, I understand that you can't have radio buttons in Access 2010 web databases. Also, is it possible to make elements appear and disappear based on a combo box selection?
If not, perhaps I could have two different combo box options: "enter yearly cost breakdown"
or "enter flat yearly cost," which open the correct respective forms as pop-ups.
So, 1) can I have Ajax-like appearing and disappearing elements as triggered by a combo box (or ideally, radio buttons), and 2) if not, can anyone think of another clever way of doing it?
Sure, you get a nice effect by using a tab control. You can place controls and even a sub form on that tab control.
So, you build a screen like this:
Then, simple set the visible property of the second tab = No. This will hide the tab (don't change this until you built the page since it will hide it! (use property sheet to hide/un-hide during development).
Now, add some code to the after update event of the list box. Like this:
In the above, I have named the tabs PYear and PFlat.
The result is this (this is a animated gif I inserted):
Of course, you really probably could just dump the whole "list box" selection, and use a screen like this with the tabs (tabs are good UI, and users tend to grasp them quick):
So, you can hide a "set" of controls, and it really far less work and hassle then writing a bunch of JaveScript anyway. As noted, the "set" of controls you drop into each of the tabs can be sub forms, and also that of continues forms. So, the "hiding" as a set does work well in this case. I did have some format issues and found that I had to "start out" with the 2nd tab dispaled first (the first one being hidden). As noted, the listbox selecting is nice, but one could likly just go with using tabs in the first place.
Is there a way to jump to the specified wizard page? Backward and forward?
For example, I would add "Configure again" button in the wpReady, and when the button is clicked, I want to jump to wpInfoBefore.
You can't, at least not sanely. It's possible to fake mouseclicks on the Back/Next buttons, and use ShouldSkipPage, which would get you the desired effect, but it's very bad practice and potentially fragile.
If the user has made a mistake in the previous pages, then they should just go back however many pages are actually required (which might not be the full complement) and fix it. This is especially important when the contents of one page are dependent on the selections made on an earlier page, as jumping back too far would typically result in some of the user's choices being discarded.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I'm writing an internal-tools webapp; one of the central pages in this tool has a whole bunch of related commands the user can execute by clicking one of a number of buttons on the page, like this:
toolbar http://img709.imageshack.us/img709/1928/commands.png
Ideally, all of the buttons would fit on one line. Ordinarily I'd do this by changing each widget from a button with a (sometimes long) text label to a simple, compact icon - e.g.
button labelled "Save" http://img337.imageshack.us/img337/773/saver.png
could be replaced by a familiar disk icon:
Unfortunately, I don't think I can do this for every button on this particular page. Some of the command buttons just don't have good visual analogs - "VDS List". Or, if I needed to add another button in the future for some other kind of list, I'd need two icons that both communicate "list-ness" and which list. So, I'm still considering this option, but I don't love it.
So it's come time for me to add yet another button to this section (don't you love internal tools?). There's not enough room on that single line to fit the new button. Aside from the icon solution I already mentioned, what would be a good* way to simplify/declutter/reduce or otherwise improve this UI?
*As per Jakob Nielsen's article, I'd like to think that a dropdown menu is not the solution.
Edit: I'm not looking for input about the icon idea. I'm looking for other solutions. Sorry my example disk icon was a small one; it was just an example. I'm showing a bigger one now to hopefully be more clear.
I would add a More Link Like Google does.
See the Top Bar of Google with WeB Images Map More >>
To this more >> drop down you can add logic to add button less frequently used by user or something like that.
If you read Jef (and Aza) Raskin, you'll probably realize that icons are also not a good solution – both were pretty vocal in their dislike for them (with very few notable exceptions). For a start they're even harder to hit than tiny buttons, then their symbols can be confusing, culture-dependent and misleading. We're already good at reading text, parsing and interpreting icons is often slower.
In any case, that button bar looks like it accommodates pretty much anyone and their dog who might be using that product. You might have had some specific scenarios in mind when creating it that should be easy to do and are important. Most likely not all buttons are needed at once for such a task to complete.
Another thing is that maybe not all buttons are even useful at any single state of the application. Can you maybe branch into different sets of buttons, depending on the state. That's only possible however, if each state has clearly defined what actions can be taken. If all buttons are equally pressable regardless of state this won't do anything.
Grouping commands according to related functionality might also be an option. This doesn't have to be done with menu-like idioms, you can also put them into containers with different background color or even color the buttons themselves (just keep in mind color blindness, though). Depending on how related those individual functions are this can be a good way of speeding up interaction. It might requier some training for users to know what the colors refer to but for an in-house tool that's only used by people you know (instead of by arbitrary random ones [which is a problem Microsoft faces quite prominently]) this should pose not much of a problem.
What if you use icons and text?
For the commonly understood commands - use just an icon (like the save)
For the uncommon commands use an Icon + the text.
If you put a border around the button as a whole it should tie the icons / text together nicely and show it's still a button. You could also do some hover effects.
Since you can't do a dropdown menu (or similar techniques like clicking a button to generate a secondary menu). The best I can think of is what Prescott did or showing an area of buttons that are grouped in such a way to make it easy for the user to know which section their button should be in.
I would start by changing some of the longer labels. At a minimum, "Application Loading" could be abbreviated "App Loading." What's another (shorter) way to say "Quick File Transfer"?
You could also group the buttons into tabs (i.e. make it a ribbon). That might work particularly well if different classes of users tend to use different, non-overlapping sets of buttons.
Numerous options:
Group and labeling. Any time you have more than eight commands, you should divide the menu items into semantic groups of about four to help the user scan for the command they want. Labeling the groups also helps the scan and can make the menu more compact. For example, Instead of VDS Ping and VDS List, Have a group labeled “VDS” with “Ping” and “List” menu items. You’ve one less word to fit in (two if you put the label above it’s associated menu items when using a horizontal orientation).
Pulldown menus. Nielsen is correct about avoiding the use of a dropdown menu for making commands. However, he’s clearly in favor of pulldown menus which look and behave like a menubar in a thick client app (Nielsen calls them “command” and “navigation” menus). I think you’ll find that there are several Javascript pulldown menus out there now, unlike back in 2000 when Nielsen wrote his post. You can fit 100s of commands in a menubar.
Sidebar menu. Arraying the menu items vertically and you should be able to fit 20 or more commands and you won’t have to shorten any command names to something user might not understand. If that’s not enough, consider a “menu bank” than combines the benefits of sidebar menu with the capacity of a pulldown menu.
Ribbon. If your commands fit into discrete tasks, where the user tends to stick to one task for a while, you can arrange the buttons on a tab control, with one sheet per task.
Command Overloading. Represent your data objects as selectable entities in your window and change your commands into more general operations, like Drill-down, Create, Copy, Move, Delete, and Link, that can be applied to various different classes of objects, thereby reducing your total number of commands. The user can select one or more data objects then select the desired command to act on them.
Work Area Attributes. Some of your commands may not be commands by settings or attributes. Remove them from the menu and represent them as data objects in the work area of the page (or another page, if they are rarely used) using controls like radio buttons, dropdown lists, and check boxes. This has the added benefit clearly showing the user the current setting as well as providing a means to change it.
Variants. For an internal app, you probably have formal roles and responsibilities that vary by work position. Include the user’s position in your model, and dynamically hide commands (and other controls and pages) that aren't relevant to that position.
What about a combobox and a Confirm button?
Or a simple dropdown menu?
Add a "Tools" or "Actions" menu bar, and stick rightmost 4 commands (or more) into the menu.
Would it be possible to implement a "most used" or "preferred" set of buttons (preferably for the user, but globally if necessary) and button to take you to the rest of the items if you need one of those?
You could group them (like the two 'vds' buttons) behind a single button that, when clicked pops a context menu with the individual icons.
It truly seems like what you're developing is a administration console which happens to present its UI through a web page, rather than something which I'd quantify as a web app. As such, especially given your statement that this is an internal use application, Jakob Nielson's advice regarding <select> tags being poor design need not apply.
For this particular set of assumptions, I think the better option is to imitate a system menu setup using one of the many CSS-based menuing designs possible.
Icons are terrible from a user experience stand point. A picture of a Floppy Disk doesn't un-equivocally mean SAVE. It means something to do with a Floppy Disk. A Floppy really, its 2010, SAVE on a web app means save to the server, how does a Floppy Disk even compute?
Here is an application that has had the same extremely usable interface for 10 years! And hardly any images for buttons, and it is one of the most productive applications in its category.
You know what ICONS stand for I ncomprehesible C ryptic O bfucsated N onsense S ymbol!
Also how do you internationalize an icon?
What would be the appropriate way for selecting a particular row in a paginated view.
For example, while trying to select a particular row in Yahoo Inbox you can use the pointer to select the check box and if you try to click beyond the check box, no action is taken.
But while trying to select a particular row in GMail Inbox you can use the pointer to select it or if you navigate away from the checkbox it changes into a thumbnail but allows you to select the row.
Which method is preferable from a usability perspective and how to implement the thumbnail based selection as done by GMail
Both methods are appropriate, and both can be very usable.
I think the main difference is that row selection (the system used by Gmail) is more like a desktop application and a little less web-like. With links (like in the Yahoo inbox or StackOverflow), it's completely obvious that you're supposed to click on them. With rows, you sort of have to figure that out that you can click them, but I doubt it takes people long.
One thing to keep in mind is that, if you go with row selection, it's probably a good idea to bunch together any other clickable control (like checkboxes, links, or "favorite" stars). This way, you can click anywhere on the row. If you intersperse controls along the row, you increase the likelihood users will make clicking errors (aiming for the row but accidentally clicking some other control), and it will make it harder for users to recognize that the row itself is a clickable region.
So, both are perfectly acceptable user interfaces. You'll have to decide which one is a better match for your particular situation. I think, in general, links are a little bit more versatile, but with clickable rows, you know you can click anywhere and it will work.
I'm making a simple Qt application. It has 4 screens/pages:
Start import
Select folder to import images to
Accept or reject each image in folder, and when no images left:
"No images left" and an OK button.
I can't figure out the best way to implement this. I started off with a QWidget, but this quickly got unmanageable.
Is a QWizard too constrained?
EDIT: Part of the problem with QWizard is it seems to always have "Back" and "Next" buttons. I don't want those as options in this program, so this leads me to believe that a wizard isn't exactly what I'm after.
I'm going to disagree slightly on using a QWizard here. It would be fairly easy to do, but in this case I think it might be easier to just use a QStackedWidget and swap the widget shown based on what you want the user to be able to do. This is likely what is done inside QWizard anyway, without some of the complication for running the buttons and moving back and forth. You also might want to take a look at the state machine stuff they're looking at adding soon, since you're application could so easily be split into states.
I think a QWizardPage is your best bet.
You can disable the 'back' on a QWizardPage by using setCommitPage(True) on it.
You'll also have to override nextId for the 'variable' amount of QWizardPages you want in between step 2 and 4.
here (basic) and here are examples of QWizards.
You can make QWizardPages for your screens and add them to a QWizard. With registerField() you can register fields to communicate between pages.
EDIT:
I didn't test this, but i guess you can control the button layout of QWizard with
setButtonLayout
Create a dialog with a "Start Import" button on top. When the user clicks this:
Populate a QFormLayout :
The layout should have a checkbox and the label is the name of the picture to import. I'm not sure of your requirements, but you could also display a thumbnail of the image.
The user just checks the images he wants.
Then at the bottom have a "Save..." button. When the user clicks this, a Save As dialog appears. You save all the checked images, discard the others.
If there are no images, change the "Save..." button text to "OK", and display a QLabel with the "No images left" string. You can switch between the QLabel and QFormLayout using a QStackedWidget.
Checkout this article on QFormLayout: http://doc.trolltech.com/qq/qq25-formlayout.html
Option: Get rid of the "Start Import" button. Have the app automatically populate the QFormLayout on startup (possibly in constructor if its fast enough).