Not letting users make mistakes vs. giving them flexibility

I'm working on a product which is meant to be simple to use and simple to set up, the competition largely requiring a long set up period and in some cases going as far as a bespoke solution for each customer. One part of our application is now expanding based on customer requests and it is looking like we'll need to make it very flexible so each customer can have a lot of control over how it behaves for them. The problem being that I don't want to make the system too configurable, as I believe this then makes it more complex to learn and to work with. I'm also concerned it opens the door to someone messing things up for themselves, kind of like handing them a gun, although I'm not actually pointing it at their foot for them.

Has anyone else faced a similar dilemma of putting power in users hands? How did you solve it? and what was the result?

From stackoverflow

• I highly recommend you read Joel's Controlling Your Environment Makes You Happy, which can be described as a treatise on user interface design but is really about usability with a healthy dab of psychology thrown in.

  The section I'm referring to is Choices:

  Every time you provide an option, you're asking the user to make a decision.

  This is something I strongly agree with. Many developers, product managers and so on take the easy route and instead of figuring out what users actually need, they just give them a choice. You see this in enterprise bloatware like Clearcase or PVCS where there are so many options--90% of which you'd never change--indicating the designers have tried to make it all things to all men rather than doing one or two things exceptionally well.

  Instead it just does lots of things badly.

  Keep it simple, follow conventions, don't overwhelm the user with pointless and unnecessary choices and make the software behave like a normal user would expect. That alone would set you apart from an awful lot of other products.

• The answer with this lies in who your end-users are. I used to write software that got used by professional sports coaches. While these guys were definitely good at what they did, they were hardly proficient at computer use, so our configurability was kept to a minimum (at least as far as what could be done in the GUI).

  On the other hand, if you're dealing with power users, adding options is usually not a bad thing as long as they aren't intrusive.

  It's all about who's going to be getting them.

• Read Jeff Atwood's Training Your Users. It's a great article with some very useful links.

• Personally I like the TurboTax model (http://turbotax.intuit.com/). When creating a tax return, I get a simple, tell-me-like-I'm-five wizard that takes me step-by-step through the process, but I can step outside the process at any time and use more advanced features, returning to the process later.

  Make it easy and simple and uncluttered for your user to do what they're going to do 80% of the time, but give them the power to deliberately step outside of the norm.

  Gavin Miller : +1 Intuit's interfaces for taxes are an excellent lesson in UI.

• I don't normally like to subscribe to the idea that all users are stupid, but there is a rule which can still be applied:

  If you give them the opportunity, they WILL break it

  Now it is up to you whether or not to give them the ability to do potentially dumb things. Or better yet, develop it so that when they do do the stupid voodoo that they do, it can be reverted or recovered from error state gracefully.

  belgariontheking : I am reminded of the Spider of Doom. Now there is a very stupid user. http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx

• I like the approach of Firefox towards this. The basic options are accessible in the option menu, all the rest is under about:config. Thus you have an easy interface and an incredible flexibility if you need it.

• Interesting timing for your question. In the U.S. this is Income Tax week. Filling out the ol' 1040 and associated subforms should give us some sympathy for what users endure.

  Lessons I take away are:

  Only ask questions that relate to the user domain; avoid questions relating to the software system; and if you can derive the answer or suggest a most likely answer, do so.

  Put related questions together (as long as they are normally entered by the same person using data most likely available at the same place and time, which is the definition of related for these purposes).

  Make it support incremental input. It should be easy to enter the data they have, and defer completing it when the rest is available.

  Show status validity and completeness. Make it clear and obvious how far they are to having validatable data.

  Make it interruptable. Make sure it's possible to interrupt the process, leave the application, come back, and resume where they left off.

  ---

  Yup, it's harder to program. Embrace it.

• I've had great success, and been happiest as an user, when using sensible defaults. In other words, make the most common use case easy (or even better, free), but give users the ability to step outside of that use case when the situation calls for it.

• There are at least two ways to build a good software product:

  1. Focus on a narrow set of functionality, and implement that functionality very well.

  2. Design your system to be customizable (ideally, through scripting.) If you do the base system right, it will be easy to provide the basic, no options, just-do-what-I-want functionality on top of the customization layer.

  Unfortunately, there are many more ways to create a bad software product.

• Your questions implies that you can either provide a flexible solution OR make it foolproof.

  I wouldn't put it like that. To me this is rather a matter of user expectations and the question in the first place would be: How can I meet all important user expectations (even if they conflict with each other) without corrupting the application?

  For instance a web application which has a menu, breadcrumb navigation, a site map and a search offers together with the inline links five different ways to find what you're looking for and how to go there. That way most users can find fast and easily the functionality they are expecting and therefore the need for an extensive documentation might actually decrease.

  So the answer might be to offer several different carefully chosen ways to solve one specific task, while each of them can be streamlined independent to avoid user mistakes.

winapi: CreateProcess but hide the process' window?

I am using CreateProcess to create a cmd.exe process that is passed a parameter that it executes and quits, this makes command prompt flash up on the screen.

I tried to avoid this by setting STARTUPINFO struct wShowWindow to SW_HIDE but this parameter seems to affect the calling window, not the window for the process that gets executed.

Is there anyway that you can use createprocess to launch a program that is hidden from view?

Also what is the proper winapi standard way to get enviroment variables?

From stackoverflow

• set the STARTF_USESHOWWINDOW in dwFlags

  by sharptooth

• The following link here describes how to create the window silently:

  DWORD RunSilent(char* strFunct, char* strstrParams)
  {
      STARTUPINFO StartupInfo;
      PROCESS_INFORMATION ProcessInfo;
      char Args[4096];
      char *pEnvCMD = NULL;
      char *pDefaultCMD = "CMD.EXE";
      ULONG rc;
  
      memset(&StartupInfo, 0, sizeof(StartupInfo));
      StartupInfo.cb = sizeof(STARTUPINFO);
      StartupInfo.dwFlags = STARTF_USESHOWWINDOW;
      StartupInfo.wShowWindow = SW_HIDE;
  
      Args[0] = 0;
  
      pEnvCMD = getenv("COMSPEC");
  
      if(pEnvCMD){
  
       strcpy(Args, pEnvCMD);
      }
      else{
       strcpy(Args, pDefaultCMD);
      }
  
      // "/c" option - Do the command then terminate the command window
      strcat(Args, " /c "); 
      //the application you would like to run from the command window
      strcat(Args, strFunct);  
      strcat(Args, " "); 
      //the parameters passed to the application being run from the command window.
      strcat(Args, strstrParams); 
  
      if (!CreateProcess( NULL, Args, NULL, NULL, FALSE,
       CREATE_NEW_CONSOLE, 
       NULL, 
       NULL,
       &StartupInfo,
       &ProcessInfo))
      {
       return GetLastError();  
      }
  
      WaitForSingleObject(ProcessInfo.hProcess, INFINITE);
      if(!GetExitCodeProcess(ProcessInfo.hProcess, &rc))
       rc = 0;
  
      CloseHandle(ProcessInfo.hThread);
      CloseHandle(ProcessInfo.hProcess);
  
      return rc;
  
  }
  

  I think getenv and setenv are all okay? I am not sure what you are asking about in that respect.

• This might be an overkill for your needs, but you can hook the ShowWindow API and never show any windows for that process

• If its just a console app you can also use the CREATE_NO_WINDOW flag as part of the CreateProcess call itself, e.g.

  CreateProcess(NULL, lpszCommandLine, NULL, NULL, FALSE, 
                CREATE_NO_WINDOW, NULL, NULL, &si, &pi);
  

  Also, see this page for information about environment variables.

how to create a custom file extension in C#?

I need help in how to create a custom file extension in my C# app. I created a basic notes management app. Right now I'm saving my notes as .rtf (note1.rtf). I want to be able to create a file extension that only my app understands (like, note.not, maybe)

From stackoverflow

• File extensions are an arbitrary choice for your formats, and it's only really dependent on your application registering a certain file extension as a file of a certain type in Windows, upon installation.

  Coming up with your own file format usually means you save that format using a format that only your application can parse. It can either be in plain text or binary, and it can even use XML or whatever format, the point is your app should be able to parse it easily.

• I think it's a matter of create the right registry values,

  or check this codeproject's article

  peSHIr : And I would let your deployment system (like a Setup project, generation an MSI, or whatever it is you use) take care of the exact details of registering.

• You can save file with whatever extension you want, just put it in file name when saving file.

  I sense that your problem is "How I can save file in something other than RTF?". You'll have to invent your own format, but you actually do not want that. You still can save RTF into file named mynote.not.

  I would advise you to keep using format which is readable from other programs. Your users will be thankful once they want to do something with their notes which is not supported by your program.

• There are two possible interpretations of your question:

  What should be the file format of my documents?

  You are saving currently your notes in the RTF format. No matter what file name extension you choose to save them as, any application that understands the RTF format will be able to open your notes, as long as the user knows that it's in RTF and points that app to that file.

  If you want to save your documents in a custom file format, so that other applications cannot read them. you need to come up with code that takes the RTF stream produced by the Rich Edit control (I assume that's what you use as editor in your app) and serializes it in a binary stream using your own format.

  I personally would not consider this worth the effort...

  What is the file name extension of my documents

  You are currently saving your documents in RTF format with .rtf file name extension. Other applications are associated with that file extension, so double-clicking on such file in Windows Explorer opens that application instead of your.

  If you want to be able to double click your file in Windows Explorer and open your app, you need to change the file name extension you are using AND create the proper association for that extension.

  The file extension associations are defined by entries in the registry. You can create these per-machine (in HKLM\Software\Classes) or per-user (in HKCU\Software\Classes), though per-machine is the most common case. For more details about the actual registry entries and links to MSDN documentation and samples, check my answer to this SO question on Vista document icon associations.

• As a deployment point, you should note that ClickOnce supports file extensions (as long as it isn't in "online only" mode). This makes it a breeze to configure the system to recognise new file extensions.

  You can find this in project properties -> Publish -> Options -> File Associations in VS2008. If you don't have VS2008 you can also do it manually, but it isn't fun.

• Can any1 provide me with a straight forward code which i can apply to my application and which wil work fine.......................thnx in advance.....

  Marc Gravell : I'd argue that the ClickOnce option is the simplest, since the VS IDE will do all the work for you.

• the problem here is we are all looking forward to a set of coding parameters to create an extension for each program; anybody that has a sample coding for it should please post it

When is it good to use embedded script language like Lua

Hi,

I'm playing WoW for about 2 years and I was quite curious about Lua which is used to write addons. Since what I've read so far about Lua was "fast", "light" and "this is great", I was wondering how and when to use it.

What is the typical situation where you will need to embed a script language like Lua in a system ?

From stackoverflow

• Rapid development for application with real-time constraints. Computer games are one of these ;-)

  Javier : other non-game apps using Lua both for extensibility and for making it easy to develop/refactor: apt, nmap, monotone, Adobe LightRoom, love2d, wildpockets

• It's a valid solution if you want to allow third parties to develop plug-ins or mods for your software.

  You could implement an API in whatever language you are using, but a script language like LUA tends to be more simple and accessible for casual developers.

• When you need end users to be able to define/change the system without requiring the system to rewritten. It's used in games to allow extensions or to allow the main game engine to remain unchanged, while allow content to be changed.

• Lua is:

  • Lightweight
  • Easy to integrate, even in an asynchronized environment such as a game
  • Easy to learn for non-programmer staff such as integrators, designers and artists

  Since games usually require all those qualities, Lua is mostly used there. Other sitation could be any application that needs some scripting functionality, but developers often opt for a little more heavy weight solution such as .Net or python.

• Embedded scripting languages work well for storing configuration information as well. Last I checked, the Mozilla family all use JavaScript for their config information.

  Next up, they are great for developing plugins. You can create a custom API to expose to the plugin developers, and the plugin developers gain a lot of freedom from having an entire language to work with.

  Another is when flat files aren't expressive enough. If you want to write data driven apps where behavior is parameterized, you'll get really tired of long strings of conditionals testing for config combinations. When this happens, you're better off writing the rules AND their evaluation into your config.

  This topic gets some coverage in the book Pragramtic Programmer.

• In addition to the scripting and configurability cases mentioned, I would simply state that Lua+C (or Lua+C++) is a perfect match for any software development. It allows one to make an engine/usage interface where engine is done in C/C++ and the behaviour or customization done in Lua.

  OS X Cocoa has Objective-C (C and Smalltalk amalgam, where language changes by the line). I find Lua+C similar, only the language changes by a source file, which to me is a better abstraction.

  The reasons why you would not want to use Lua are also noteworthy. Because it hardly has a good debugger. Then again, people hardly seem to need one either. :)

• In addition to all the excellent reasons mentioned by others, Embedding Lua in C is very helpful when you need to manipulate text, work with files, or just need a higher level language. Lua has lots of nifty feature (Tables, functions are first class values, lots of other good stuff). Also, while lua isn't as fast as C or C++, it's pretty quick for an interpreted language.

• a scripting language like LUA can also be used if you have to change code (with immediate effect) while the application is running. one may not see this in wow, because as far as i remember the code is loaded at the start (and not rechecked and reloaded while running).

  but think of another example: webserver and scripting language - (thankfully) you can change your php code without having to recompile apache or restart apache.

  steve yegge did that thing for his own mmorpg engine powering wyvern, using jython or rhino and javascript (can't remember). he wrote the core engine in java, but the program logic in python/javascript.

  the effect of this is:

  • he doesn't have to restart the core engine when changing the scripts, because that would disconnect all the players
  • he can let others do the simpler programming like defining new items and monsters without exposing all the critical code to them
  • sandboxing: if an error happens inside the script, you may be able to handle it gracefully without endangering the surrounding application

Access the BPM ID3 tag in iPhone OS 3.0

Is there any way to access the BPM (beats per minute) ID3 tag of a song on your iPod using the iPhone OS 3.0 SDK? I'm looking at

https://developer.apple.com/iphone/prerelease/library/documentation/MediaPlayer/Reference/MPMediaItem_ClassReference/Reference/Reference.html

and i don't see it:

NSString const MPMediaItemPropertyPersistentID;      / filterable */
NSString const MPMediaItemPropertyMediaType;         / filterable */
NSString const MPMediaItemPropertyTitle;             / filterable */
NSString const MPMediaItemPropertyAlbumTitle;        / filterable */
NSString const MPMediaItemPropertyPodcastTitle;      / filterable */
NSString const MPMediaItemPropertyArtist;            / filterable */
NSString const MPMediaItemPropertyAlbumArtist;       / filterable */
NSString const MPMediaItemPropertyGenre;             / filterable */
NSString const MPMediaItemPropertyComposer;          / filterable */
NSString *const MPMediaItemPropertyPlaybackDuration;
NSString *const MPMediaItemPropertyAlbumTrackNumber;
NSString *const MPMediaItemPropertyAlbumTrackCount;
NSString *const MPMediaItemPropertyDiscNumber;
NSString *const MPMediaItemPropertyDiscCount;
NSString *const MPMediaItemPropertyArtwork;
NSString *const MPMediaItemPropertyLyrics;
NSString const MPMediaItemPropertyIsCompilation;     / filterable */

From stackoverflow

• If you don't see it, submit a Radar to have it included, or perhaps to ask for an API with a more general means of querying tag values.

Custom about dialogs in Eclipse applications

Hi,

I have an Eclipse workbench application composed of many plugins. I'd like to set the about text of the app to reflect the build number.

There seems to be a couple of places to do this: - Inside the application's .product file (setting text here doesn't seem to do anything?) - Inside the plugin.xml file of the main plugin (this does seem to work).

I have two questions:

1. What is the best way to achieve this? via plugin.xml?
2. Why is the text I set in the product file ignored?

From stackoverflow

• It (text and picture of an about dialog) should be in the about.ini of a feature or product plugin.

  

  Note: for the picture, this blog entry "How Can I Give My Eclipse Blob An Icon In The Flippin’ About Dialog?" is quite nice.

  Notebis: with the latest 3.5Mx releases, the about box is even more configurable.

  Daniel : Nice post! Thank you. I think I'll have to revise our approach to branding to something more Feature oriented. Any ideas why the various plugins/products have spots for setting about info as well? Is there any use for these fields?

How to markup scientific names in XHTML?

I would like to know the best way to markup scientific names in XHTML. This answer says I should use the <i> element, which I'm not too in favour of, unless of course, it is the right element to use.

I could use <span class="scientific">, but seeing as one of the first uses of HTML was to markup scientific documents, I'd imagine there'd be a better semantic hook for this sort of thing.

Also, is there any element to markup the common name of a scientific name?

Note: It looks like Wikipedia, or at lease this article is using <i> for scientific nams.

Edit: Would the <dfn> tag be appropiate?

From stackoverflow

• dfn is for a definition of something.

  <p>The prefix cardio- means <dfn>of the heart</dfn>.</p>
  

  As far as I can see in the list of HTML 4 elements nothing specifically fits the bill. This leaves you with a few options:

  <span class="scientific">cardio</span>
  

  The semantics are added by the class, and so this is probably the most correct way, technically. However, it does have the downside that without your CSS, it won't appear different in any way to the surrounding text. Another option might be this: /me prepares to duck for cover

  <i class="scientific">cardio</i>
  

  Now before I get my head bitten off for using the verboten element, <i>, consider that it is no less descriptive than using <span>, and even if a stylesheet were missing, you'd still get vaguely the correct formatting. Just make sure you add the class attribute.

  alex : Good answer, Nick. Hopefully you don't incur any downvotes from people who see and go urgh! I think I'll go with as it is used by Wikipedia and it seems to fit the bill. Thanks for the answer.

  nickf : oh, Wikipedia doesn't use any semantics at all in its markup, so I wouldn't use it as a guide. Click Edit on any page and you'll see why. Rather than get their users to learn the correct classes to use, etc, they go for a very simple markup... one step back from WYSIWYG, really.

  alex : Yeh, and I bet they don't use or with their revisions?

  nickf : haha oh man, that'd be so messy.

  alex : Nick, according to http://htmlhelp.com/reference/html40/deprecated.html it hasn't been deprecated, just has lost it's presentational meaning... it does not mean italicize text anymore...

  alex : it's also listed here: http://www.w3.org/TR/html401/index/elements.html

  nickf : oh, well there you go!

  alex : It's interesting... most people (including me until recently) though and were deprecated.

  porneL : Your example is wrong. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-dfn-element It should be

  The prefix cardio- means of the heart.

  nickf : oh that's... well... different to what I had expected. Looks like dfn might actually be the right way to do it!