We are currently trying to improve our usability in our intranet web app. One of our goals is to declutter certain pages which have large Grids on them. To do this, we have started putting commonly used actions (like Delete, Reset To Zero, Mark As Complete, etc.) in the grids as functions.
My initial idea was to find and use icons (i.e. Delete = a big red x, Reset = an arrow curving around itself, Mark As Complete a checkmark, etc.) to represent these tasks. Some of my coworkers agree with me; they say the icons make the tool look more professional. Others, however, say that icons obscure their intended function, and simple text such as Delete would be more appropriate.
Assuming that we will include a tooltip description of the function regardless of the type we choose (icons or text), which one is more usable? Can we use icons for some actions and text for others, or will that hurt usability?
Using icons for some functions and text for others probably isn't very consistent (unless you follow established idioms such as toolbars and menus, which are both places for commands, even though one is for icons, the other one for labels – doesn't mean that it's a good idiom, though).
To quote from Jef Raskin's The Humane Interface:
In every study that considered the question, icons were demonstrated to be more difficult to understand than were labels, especially at first viewing, which contradicts one of the most frequently cited reasons for using icons, namely, comprehensibility for beginners. GUIs often present us with windows full of identical icons, each with a label. The icons are small and numerous, and there are dozens of different icons. The limited conditions under which icons are effective do not obtain in present computer systems.
Although it is true that tiny icons can take less screen space than labels, you have to ask: At what cost? The smaller a button, the longer it takes to operate it, and the more difficult it is to find; also, it is difficult to make a small icon distinctive. Another small point: Icons take more time to create than do words.
and
Mayhew [1] cites a number of research studies on the use of icons. Unfortunately, most of the studies did not compare labels to icons. But from these and other studies, we can conclude that icons are most effective when there are at most a dozen of them and when at most a dozen are seen at one time. In addition, it is essential that they
Are visually distinct
Do a good job of representing the appropriate concept
Are presented at a reasonably large size, typically larger than a text label would be
[1] Mayhew, Deborah. Principles and Guidelines in Software User Interface Design (Englewood Cliffs, NJ.: Prentice-Hall, 1992).
I'd agree with Raskin on this point that in many cases icons really obscure the meaning of concepts and commands and you need additional text anyway to explain them. Aza Raskin's article The End of an Icon is a good read on this as well.
I'm a big fan of icons. Heck, the textarea I'm typing this answer into right now has nothing but icons on top of it. You've got to be a moron not to know that a big dark B means bold... I think if your icon is self explanatory (like a big red X for delete etc) then that's for sure the way to go. It also makes it easier for the user to find the right action.
I would use icons seen in Windows applications like Microsoft Word and Excel. Most users a familiar with these and their meaning/functionality.
Also; usability proceeds "the professional look". It sounds to me like your application needs to be functional and not a design masterpiece. Therefore your main concern is to have your interface communicate its functionality as clear as possible, so tap into your users knowledge--again; chances are that your users are using Word and Excel on a regular basis.
To top things off; make use of the alt and title properties on image elements:
<img
src="..."
alt="Click this button to delete X"
title="Click this button to delete X" />
I've seen both implementations work with great success. It really depends more on your target audience. Interestingly enough, there are a group of folks where I work that still expect to see text type buttons/links for their actions, so I've tailored those particular apps accordingly. Just provide both options initially and see which one the user base is more comfortable with.
If you can get away with it, can you make your icons large enough that you can embed the text of each action within it? Say a large red X with a small "Delete" text right below it, embedded into the image? I find that that will often suit both groups accordingly.
Icons save space (and with tooltip can be quite usable by beginners), but mixing icons and text would not be a good idea, requiring user effort to "switch". Why not, instead, put "rare" actions into a section of the page that's normally "folded shut" and only opens up when clicked? This saves even more space and clutter, after all.
If it's an obscure function, then icons would probably hurt usability. However, I think pretty much everyone has accepted and understand delete, refresh, etc. As long as you have the tooltips to fall back on, you should be fine.
We always use text in our company, we used to have a product with icons, and got many complains from the clients, for some reason, those icon made the user make wrong operations, especially when they were doing many things at the same time, for example, talking on the phone and entering data.
Personally, I think if the operation is very simple, then icon is fine, but if there are several tasks listed together, it maybe confusing.
Related
I do have a C# application that calculates storage space in terms of boxes, for some products which itself consist of several parts.
The calculation includes suggestions on how many single parts to put into one box, taking in account volume and weight of the part. The overall result states the number of boxes needed for a given quantity of products.
As of now I am putting the results into a database and then copy it into an Excel file. Furthermore I am creating some charts to better visualize the numbers.
I am not satisfied with this solution. I do however have no idea, on how to programmatically produce a printing output. I am familiar with standard printing in C#, but woking with various sized tables and charts there just seems wrong and an awful lot of work to me.
I have to admit I am lacking some experience in this field, therefore I would be pleased to hear from you on this matter.
The short answer is, it is going to take a good amount of work. I think the most important step towards coming up with a solution is stepping back and realizing everything that needs to be printed and how you would handle it if you were a printer (sounds weird, I know!).
You're going to want to write your own DocumentPaginator and draw elements for each page in the overriden DocumentPaginator.GetPage method. The DocumentPaginator is what the printer uses to print documents, so it calls the GetPage method and you can send it a DocumentPage with user controls drawn on it. You also have to be able to do things like calculate how many pages to print, so keep that in mind.
Since they are different sizes you have a couple options that I can think of:
Only draw (scale) the tables/charts to be the width of the maximum size of the page being printed
Draw 1 visual per page (I would suggest keeping them all landscape or all portrait oriented to keep it simpler for now)
Basically if you're going to use the PrintDialog's dialog for the user to select the printer and printer preferences, it'll save you some work. If you don't want to show a dialog, then you will need to become fimiliar with PrintDialog, PrintQueue, XpsDocumentWriter, PrintTicket, PrinterCapabilities, PrintServer, and DocumentPaginator.
Note: If you allow a users to print 1 control across multiple pages, realize that providing "half drawn" controls and/or printing both "vertically" and "horizontally" adds another degree of complexity.
I am tasked to write a .NET application that displays a slide-show with some information (words or images) and when the user sees certain items, s/he must immediately press space and the time of the key press must be recorded. The items will be displayed one after the other, for about 50ms. I need then to evaluate the difference between the timestamp of the keypress and and the one when the slideshow started (so I will know how long it took the user to react on the presented item). Edit: I must also record the time of the occurence of the special item.
I need to reduce any unpredictable lags that may occur as the application is running, so that the input processing is as realistic as possible, as well as to reduce any lags between the slides. Currently I am thinking of 3 approaches:
Write a standard Windows Forms (GDI+) application.
Write a WPF application
Write a DirectX-enabled windows forms application that utilizes the Tom Miller's Render loop concept (it is praised as effective in terms of performance).
Something else that you might suggest
I must clarify that I will not use advanced display techniques, special effects or designed for the purpose 3D environments - just plain text slides in different fonts and colours, or images. Unfortunately I cannot cite my sources, but I have read that Windows Forms and GDI+ cannot provide me with the desired accuracy. So, is WPF going to provide me with a better solution? Do I need to use the render loop, or some other approach. I am not experienced in such type of performance requirements for desktop applications, and all advices will be appreciated greatly.
I personally love WPF, but I would be very wary of using it for this application. It is not going to have the same time precision as GDI+ or DirectX. There are all sorts things you'll have to work with like the DispatchTimer and it just wasn't build for something like this. WPF is a whole set of gigantic abstractions on top of graphics and the farther you get away from the metal, you're introducing potential problems. If you want to put a video projected on top of a 3D sphere inside a combobox then WPF is the way to go, but if you need accuracy/precision on the scale you're talking, WPF is not the answer. I don't know where you read that WPF will provide you with better accuracy, I can practically guarantee that it will not.
DirectX would most likely be the most accurate in ensuring that a picture is only displayed for 50ms at a time. But GDI+ would be a decent alternative solution because it will make it easier to deal with text from a programming perspective.
Another consideration, screen refresh rates. yikes. if you do the math most LCDs have a 5ms response rate which is 10% of your allotted time. That and they only display at 60Hz. If you're displaying 20 pictures per second (50ms per picture) it is only going to be on the screen for 3 refresh cycles.
I hope this helps.
50 msec isn't long. Maybe encode and play the slideshow as a video?
I'm in the process of writing a small text-editor that is supposed to have very basic formatting capabilities, nothing fancy, yet more complex than what RichTextBox can provide (including a 'page' display functionality).
However, last time I wrote any text editors was with WinAPI in C for Windows 3.1. I have no idea on how to approach this with .NET. The furthers I've gotten until a blank is using TextRenderer.DrawText() to output the text I have into a rectangle... but something tells me that's not the way to go in this case, because I've thought all along that for one, I will want the background text in XML format... and while I can break up the paragraphs with tags, I have no clue how to do the formatting, such as or a different font family, so it probably need to be approached a little differently. Probably each word separately. Do I have to keep each word in an array (with respecting xml tags) and draw it as a separate control keeping its positions in an array as well? That sounds like an awful lot of memory and drawing power if we're talking about hundreds of thousands of words in one file (it's a possibility, although I highly doubt one file would extend beyond 20000 words, however anything's possible and together with the word's points (formatting is only available to full words, so no worry about that) it may grow pretty big with memory usage, something that I don't particulary prefer to happen.
So... what I'm looking for is a few hints and tips (I can't use Tx Text Editor, DevExpress or Telerik's RichTextEditors for a good reason plus their price). on the most correct way to build a 'word processor' that is well extendable with C#.NET as it's the one thing I have so far never had to stick my nose into.
Basically:
1) Best way to draw text into a custom control. How should I keep my text? I will probably use the base Text property for pre-formatting stage when I load the files. Or perhaps I'll extend it with my custom XML class? Should I keep words in order in position and joining them by hand when backspace is used? Etc etc.
2) Best way to do selection (probably only one way I presume?), while in WinAPI I could just detect the character under cursor as it was standard text, considering the amount of fonts and the way windows draws the characters I would either have to OCR and then start calculating position... so I presume there's a better way of selecting text?
3) Editing text - which I would assume is simple once I have a cursor position.
Cheers for reading and... hopefully someone comes up with a better solution than my feeble DrawText which... isn't really the solution.
If you're looking to create a more fully-functional text editor in WPF, you might want to start with this sample and work on from there.
I have a requirement to present in my c# windows application a "map" of a building, with different rooms coloured in various ways to indicate various things. This needs to be renderable at different sizes and from different perspectives, and needs not to be a one off exercise, but a repeatable process for different establishments.
I am thinking of it in terms of an old school level editor (think old ID stuff), the product of which can be rendered top down; it sounds like an awful lot of work to get into designing my own editing tool, so am looking for a way to hook an existing tool into c#.
I have got the .NET drawing code down (if need be), and I have got the Adobe Illustrator design down (again, if need be) - what I am looking for is a way to link the two, or (if appropriate) a suggestion to use something different in those two roles entirely. Any and all suggestions very gratefully received, thank you!
I'd look at Microsoft Visio - it seems more appropriate for architectural/schematic diagrams than Illustrator and there should be already .NET libraries to use Visio-generated drawings.
I don't want to use flash because it won't allow me to dynamically modify (add, remove) the pictures through my application so I thought about javascript (JQuery Plugins). but the problem is visitors can save the pictures and I don't want that to happen! .. so any ideas ?
Edit
I really appreciate your help and honesty but is JavaScript to have a dynamic modifiable SlideShow for my websites ? .. I don't care about screenshots, what's important is the original picture that I think will be downloaded to the visitor temp files!
The best you can do is a mild deterrent. I've written an HTML5 slideshow used by many. It offers right-click warning to those using it, but it is best referred to as a warning rather than a protection.
First off, if a browser can display an image, any viewer can get them too - no matter what you do - that's just the way the web works. If you really need them protected, then you need to use a significant semi-transparent watermark that touches important parts of the image or limit the viewing only to people who you trust.
If you're interested in a mild deterrent that can still be bypassed quickly by anyone who understands how a browser works, but might slow down non-sophisticated users, then you can implement a couple forms of click protection that make it harder to right-click save your images. Right click protection works best when the actual image you are displaying is not the top level image. This can be done by displaying a transparent image over the top of your slides. This will not be seen, but if a viewer succeeds in getting to a right-click-save menu, all they will succeed in saving is the empty transparent image on top. You can literally use a 1x1 transparent gif image which is tiny and then scale it up to the size of your image to cover it. It will not be seen, but it will defeat right-click save.
It is also common to also put in some javascript that attempts to intercept the right-click operation to prevent that, though this protection is blocked by more and more browsers now (like Firefox 4+) and is far from foolproof. It should not be relied upon.
In the end, these extra steps are only a mild deterrent and will only work with non-sophisticated viewers who aren't very determined. Because, even with the maximum protection in place, one can still look at the media list in the browser and see all the image URLs in the web page or look at the source or DOM or network trace of the web page to see what the URL is of the images that are being displayed. Once the URLs are known, the images can be saved easily. The danger of this kind of protection is that content owners believe it's real protection and they put images at risk that they shouldn't (without good watermarks on them). But, if you fully understand what you're getting (and not getting), you can do it.
It is impossible to Really protect them. If the user can see the image, then the user's browser has downloaded it. So the user has the image on their computer and can do anything they want with it.
There are lots of ways of making it harder for the user though. Disabling right clicking is one way.
If you really need to hide them badly you could use the data uri scheme too, but it really won't stop someone who really wants to get it:
http://en.wikipedia.org/wiki/Data_URI_scheme
You will not be able to protect your images unless you use a watermark which not what you're looking for as I understand you.
You need to remember that the user will always have his printscreen button and many tools that can do the job and that you can't control anyway
Break up your images into pieces, or possibly even embed them in larger junk images. Then use CSS to display the multiple overlapping divs with appropriate background styles to position the pieces where they need to be so to the user they look like one image, kinda like how google maps looks like one large image but is actually made up of many small ones. The user won't know the difference, but if they try to save them locally they'll just get one piece at a time.
Of course, that only works until they realize they can do a print-screen, but it's something. :-)
It is impossible to completely protect your images.
Seriously, if the user can see it in their browser they can save it to their computer.
You are fighting a losing battle here.
Even if you watermark your images, a good graphics program can countact that.
The best thing to do is only display small, low quality images that people wouldn't want to keep anyway.