I want to make a user interface for a string builder that I want to build for some users. The problem is the users sometimes have zero tech back ground. I want to know when I am not making it too complicated for my users to understand.
For example I want include a filter option for users to choose what computers they would like to select for a virus scan under a domain. Now I have to create a string builder that look like something like This
* "user input content" * or
* "user input" or
"user input" * "user input2" *
etc
now all I can think about is to give the user something like
name contains _____ ;
which only covers * "content" *
This lead me thinking about create a customized string builder for users to grab all the computers they want to scan.
eg. build your own filter ______ then provide a list of pre-defined keywords such as before, contain, anything, after that users can select and add their own words behind these keywords as filters. But then I am scared that is much too complicated as they would not know how. So I need help trying to find out When is it too complected or not for general public and if possible some suggestions on the particular case I have listed above.
You might consider something like what Brett Victor did with his Proposition 21 example where the text is largely in place with default values already filled in, but where there are user controls to interactively adjust the values.
Alternately, you could just have a single field which, without any special characters, does a simple "contains" search across the relevant fields, but which supports additional syntax (described by a '?' button) for your more advanced users.
Related
I have outlook 2011 in my mac. I have more than 30,000 emails in my mail box and would like to search from all the mails based on inputs.
Now using Advanced find I can do that , But for each and every value I have to add a new search criteria
eg . Subject contains xxx
Subject contains yyy
Subject contains zzz
it would be very difficult for me to add the search value manually if I have 1000 values to search for.
Is there any effective way to do this or do we some plugin which would read from input file and populate these vales ?
Any help would be really appreciated
I think, you can get little bit help from this -- http://derflounder.wordpress.com/2011/04/26/finding-the-hidden-search-options-in-outlook-2011/ , also this one too - https://www.gvsu.edu/cms3/assets/428A2C9A-0FB7-5B0C-BBFCF723C12E59E3/outlook_mac_search_email.pdf
In Windows version of Outlook there is a hidden tab that can be enabled by creating a new registry key HKEY_CURRENT_USER\Software \Microsoft\Office\12.0\Outlook\QueryBuilder. See here (sroll to Building DASL Queries).
This adds SQL tab to Filter dialog of Customize Current View. Here you can write a text with DASL query. The query for your example would look like this:
("urn:schemas:httpmail:subject" LIKE '%xxx%' AND
"urn:schemas:httpmail:subject" LIKE '%yyy%' AND
"urn:schemas:httpmail:subject" LIKE '%zzz%')
You can create script that takes all keywords from a text file and formats them like
"urn:schemas:httpmail:subject" LIKE '%MyKeyword%'
and construct the DASL query prorgamatically from a text file. You can store your generated queries as text files and copy them in the SQL tab as necessary.
This solution is surely far from perfect but it is relatively easy to implement. The problem is that I do not know how to enable that tab in Outlook 2011 on Mac nor whether it is possible at all. I do not have a Mac so take this rather as a hint.
I'm implementing a native iOS application, which provides a feature to search for articles using keywords and several search filters such as author, year, publisher etc. Each of these search filters has several options such as 2014, 2013, and 2012 for the year filter, or Academe Research Journals, Annex Publishers, and Elmer Press for the publisher filter. Each of these options has a BOOL stating whether the option is selected or not. I need an object that wraps the search keywords and search filters so that I can send it to the server, which is responsible for the search operation.
Which data structure should I use to represent these search filters in the wrapper class?
Something like XML comes to mind:
<year>2014</year>
<publisher>Annex Publishers</publisher>
Although I find it rather bulky. I'd probably prefer something like:
year=2014|publisher=Annex Publishers
You'll need to escape = and | appearing in the field names or values, but this is easy to do.
This could just be a single string sent across.
In terms of actual data structures, you could have a map of field name to value, only containing entries where the option is selected. Or you could have a class containing pointers / references for each field, set to null if the option is not selected.
Another totally different consideration is to use an enumerated type, i.e. mapping each possible value to an integer, typically resulting in less memory used and faster (and possibly more robust) code, depending on how exactly this is done.
You could map it as follows, for example:
Academe Research Journals 0
Annex Publishers 1
Elmer Press 2
Then, rather than sending "Annex Publishers" as publisher, you could just send 1.
year=2014|publisher=1
The extension for multiple possible values for a field can be done in various ways, but it's fairly easy to do:
<year>2014</year>
<year>2013</year>
<publisher>Annex Publishers</publisher>
Or:
year=2014,2013|publisher=Annex Publishers
Is something like this not possible with a wildcard? I'm trying to send an article to people who do not have any preferences, and if they do have preferences don't show it. I cannot find any documentation on it.
Thanks in advance
*The star means all groups
*|INTERESTED:*|*
//Do nothing
*|ELSE:|*
//Show all
*|END:INTERESTED:|*
No, MailChimp's conditional merge tags don't support wildcards inside of those merge tags.
If the end goal is to show X content to subscribers who have no group affiliations and show Y content to subscribers who have any group affiliations, there are a few ways to accomplish this.
a) You can use *|INTERESTED:GroupTitle:GroupName1,GroupName2,GroupName3|*, etc. to show content to any members of those 3 groups. If you have more than that, of course, just add all of your groups in there with that comma-seperated format. Then, use the *|ELSE:|* as you already are in your example to account for people who aren't tied to any of those groups. This can be tedious though if you have a ton of groups.
b) Consider sending two separate campaigns, each set to send to a segment of your list that targets based on group affiliations (or non-affiliations).
sources:
http://kb.mailchimp.com/article/how-do-i-use-smart-merge-tags-with-groups/
http://kb.mailchimp.com/article/how-can-i-send-to-a-segment-of-my-list/
I am developing a ERP software inhouse and one of the requests is to have the the username of the person creating any document to appear on the window title when that document is opened.
It will be something like [USR] - Transport Order 123456
Are there any usability rules that I am not adhering to by doing this? It just looks a bit unprofessional to have [] in the window title.
Any ideas?
There's nothing wrong with that at all. As a matter of fact, many of the biggest ERP applications do similar things.
In my opinion, though, the first part of the title should either be the name of the application or the name of the window. Anything else should go after that. It just makes it easier to read.
Something like this, maybe:
ApplicationName - Transport Order 123456 - UserName
Both the Windows UX Guidelines and Apple HIG have rules for naming windows. However, the specific rules are oriented towards document-type applications rather than database-type applications like ERP. Nonetheless the general principles apply.
The primary purpose of the window title is to make it easy for users to distinguish their windows. For this reason both Windows UX Guidelines and Apple HIG recommend windows be titled by their content, since that is usually what users will be looking for to choose a window to click on. Other potentially useful information, like the program name, may follow the content identity. The Windows UX Guidelines, for example recommends a “document name – program name” format (p316). You want the most distinguishing information first in the title so it's easiest to see, especially when looking at the task bar for which the name is often truncated. Also, the icon represents the program identity, so the program name is a little redundant anyway.
Multi-window ERP apps likewise should distinguish their windows by their content. Thus generally, the title should start with the window name, identifying the class of data shown in the window, followed by any filtering or querying criteria of the data. This order assumes users are more likely to have open two different windows than two instances of the same window with different filtering criteria. The title may end with the program or application name, if you think it’s necessary. So an example title would be something like:
Shipments (Ship Date: 2008-01-01 to 2010-01-01) ERP-O-Rama
It may be helpful to include the user who created or "owns" the data if that is different than the user currently looking at the data, but that still doesn't sound like something that distinguishes windows -are users going to be looking two different versions of the same content created by two different users? It seems at best to be secondary information to put at the end of the title if there at all. Why do users need to know this? Perhaps it should be a field in the window or a property in a Properties dialog.
You certainly don't need the current user's name in the title, unless users can be simultaneously logged in under different identities (e.g., they’re Jakob Nielsen for one window but Jared Spool for another). Users generally know who they are, so it seems like unnecessary clutter to me. If users may be logged in as different users or roles for different sessions (which is generally not a good idea) then you may want to represent that in the status bar, but not the title bar.
Brackets vs. parentheses vs. dashes seem like a matter of taste to me. Windows generally prefers em-dashes. My only advice is to use them only when necessary to delimit substrings. "[USR]" doesn't seem appropriate unless there may be spaces in the username.
Do your users care if you break a "usability rule", so long as what you do makes the program more usable? That is, if putting the username in the title enhances usability for your specific users, strict adherence to some standard comes secondary.
Put the needs of your user first. If putting the user's name in the title bar enhances usability, by all means do it.
I recommend something like
123456 - Joe User
The square brackets aren't necessary, and neither is the phrase "Transport Order" unless you need them for disambiguation.
I've read somewhere (can't remember/find where) an article about web usability describing when to use drop downs and when to use autocomplete fields.
Basically, the article says that the human brain cannot store more then the last five options presented to choose.
For example, in a profile form, where there is your current occupation, and the system gives you a bunch of options, when you read the sixth options, your brain can't remember the first one anymore. This example is a great place to use an autocomplete field, where the user types something that he thinks that would be his occupation and then select the better from the few options filtered.
I would like to hear your opinion about this subject.
When should I use a drop-down and when I should use a Autocomplete field?
For a limited list, don't use an autocomplete edit box or combobox, but use a listbox where all values are visible all at once. For limited lists, especially with static content of up to about 8 items, this takes up real estate, but presents the user with a better immediate overview.
For less than 5 items a radiogroup or checkbox group (multiple selections) may also be better.
For lists whose content is dynamic, like a list of contacts, a (scrolling) listbox or combobox are appropriate because you never know how many items will be in the list. To keep it manageable, you will need to allow for some kind of filtering and/or autocomplete.
Autocomplete usually suffers from the fact that what the users types needs to match a string from the beginning. I hate those except for when they are used to complete a value based on what I typed in that (type of) field before. E.g. what browsers nowadays offer when filling out online forms.
Allowing a user to start typing in a combobox usually suffers the same drawback. But admittedly it doesn't need to if the filtering is based on "like %abc%" instead of "starts with abc"
When dealing with lists that can have many similar items, I really like the way GMail's "To" field handles it. You start typing any part of someone's name or e-mail address and GMail will drop down a list presenting all the contacts whose name or e-mail address contains the characters you have typed so far anywhere within them. Using the up and down keys changes the selection in the dropped down list (without affecting what you have typed) and pressing enter adds the currently selected item to the "To" field. By far the best user experience I have had so far when having to select something from a list.
Haven't found any components yet that can do this, but it's not too hard to "fake" by combining an edit box and a listbox that drops down when you start typing and has its contents is filtered based on what has been typed so far.
I would use 2 criteria,
1) How long is the list, if the list contains 5 elements you better use a combobox as it will be easier for the user (better UX)
2) In case the list is long, how easy for the user to remember the prefix of what he/she is looking for... if it's not easy, using autocomplete is irrelevant..
I'd say it depends on the diversity in the list, and the familiarity with the list items.
If for example the list contained over 5 car brands (list items I'm familiar with), no problem.
If on the other hand the list has over 5 last names, it could take me some more time before I'd make a selection.
You should probably just try out both options and trust your gut on which you find easier to use.
Here's the opposite approach:
The worst time to use an auto-complete box is when you have a finite and relatively small set of options, and the user doesn't know the range of valid options. For example, if you're selling used cars and you have a mixed bag of brands, simply listing the brands in a combobox is more efficient and easier to browse than an auto-complete method.
Being able to remember the last 5 options is most likely irrelevant unless you have a giant list of options and are requiring the user to select the most relevant item.
An alternative approach is to use both. I believe Dojo has a widget that acts as both a combobox and an auto-complete field. You can either choose to start typing and it will narrow down the possible options, or you can interact with it with your mouse and browse it like a combobox.
I usually look at how big the list is going to be. If there are going to be more than 15 options then it just seems easier to find if they can just start typing.
The other circumstance for me is when there is an other option and they can free type it. This essentially eliminates the need for two controls since you can combine in one.
The main difference has nothing to do with usability but more to do with what defines the acceptable inputs.
You normally use a ComboBox when you have a predefined list of acceptable inputs (e.g. an Enum or list of occupations).
An auto-complete field is best used when there are many known inputs BUT custom input is accepted as well. The user will become frustrated if they type "Programmer" in as their occupation but it wasn't one of the pre-defined, acceptable inputs, and they are given a message that their input is not valid.
Keep in mind that ComboBoxes do allow you to type in them to select the first matching option. Some types of ComboBoxes (depending on the UI framework you are using) even allow free-form text fields at the top or side of the field to search or add to the list.
Of coarse the best way to determine what YOUR user will prefer is testing: A/B, field, user, etc.
Hope this helps you solve your dilemma!