Python Used for Common User Interface Needs

My upcoming book, Beginning Programming with Python For Dummies, describes how to start working with Python. You discover how to perform all the basics and I even provide a few real world examples. However, once you’re done with the book, you might ask how Python can be used for real world programming of the sort that you need to do. One of the most common tasks is creating a user interface. Just about every application out there requires a user interface and it has become popular to make user interfaces touchable. Fortunately, Python developers have access to a huge number of libraries to make seemingly hard tasks simple. In fact, that’s one of the advantages of using Python—the immense number of really practical and useful libraries at your disposal. It’s possible to find a library for just about any need.

One of the more interesting libraries available for Python is Kivy. This library makes it possible to create multitouch applications without having to do all the heavy lifting yourself. The interesting thing about using Kivy for this task is that it helps you avoid some of the problems with other sort of multitouch application environments, such as using a combination of HTML5, CSS3, and JavaScript (where a less than compatible browser can ruin your chances of making the application work properly). This is a native code library that works on the Linux, Windows, OS X, Android and iOS platforms, so you have a good chance of finding precisely the support you need in a package that will perform well on the chosen platforms. Like all Python applications, the application you create on the Mac will work just fine on Windows too.

Of course, there are tons of libraries for Python, so why did I choose to talk about this particular library? It turns out that Kivy is proactive about obtaining as much developer support as possible, to the point of running contests (yes, that’s more than one of them) to see what sorts of things people can do with Kivy. I’ll admit it, I was bedazzled looking at all the eye candy on this site. What I thought was a five minute scan of the example applications turned out to be more than an hour of perusing what’s possible with Kivy and Python. All you need to do to try one of the applications out is to click its link, download the code, and start running it. Nothing could be easier (or time consuming as it turns out). Soon, you’ll find your days consumed by checking out Kivy applications too.

Fortunately, Kivy is also free. All you need to do is download the copy for your platform and install it. So, you get this great library that you can use for your business applications and it doesn’t cost you a dime. What I’d most like to hear about is whether someone is using Kivy in a large scale business application and how its performing for them. Speed is always an issue with Python, despite all the other amazing features it provides, so finding libraries that use every bit of speed Python has to offer is essential.

I take a lot of time looking for various tools, libraries, applications, and other resources for readers to use with my books. I’m not looking for anything cheesy, crippled, or difficult to use—I want well written, popular, and preferably free resources I can share. If you have a resource that specifically meets the needs of my readers, please let me know about it at


Considering Perception in User Interface Design

I read a couple of articles recently that reminded me of a user interface design discussion I once had with a friend of mine. First, let’s discuss the articles. The first, New Record for Human Brain: Fastest Time to See an Image, says that humans can actually see something in as little as 13 ms. That short time frame provides the information the brain needs to target a point of visual focus. This article leads into the second, ‘Sixth Sense’ Can Be Explained by Science. In this case, the author explains how the sixth sense that many people relate as being supernatural in origin is actually explainable through scientific means. The brain detects a change-probably as a result of that 13 ms view-and informs the rest of the mind about it. However, the change hasn’t been targeted for closer inspection, so the viewer can’t articulate the change. In short, you know the change is there, but you can’t say what has actually changed.

So, you might wonder what this has to do with site design. It turns out that you can use these facts to help focus user attention on specific locations on your site. Now, I’m not talking here about the use of subliminal perception, which is clearly illegal in many locations. Rather, it’s possible to do as a friend suggested in designing a site and change a small, but noticeable, element each time a page is reloaded. Of course, you need not reload the entire page. Technologies such as Asynchronous JavaScript And XML (AJAX) make it possible to reload just a single element as needed. (Of course, changing a single element in a desktop application is incredibly easy because nothing special is needed to do it.) The point of making this change is to cause the viewer to look harder at the element you most want them to focus on. It’s just another method for ensuring that the right area of a page or other user interface element gets viewed.

However, the articles also make for interesting thoughts about the whole issue of user interface design. Presentation is an important part of design. Your application must use good design principles to attract attention. However, these articles also present the idea of time as a factor in designing the user interface. For example, the order in which application elements load is important because the brain can perceive the difference. You might not consciously register that element A loaded some number of milliseconds sooner than element B, but subconsciously, element A attracts more attention because it registered first and your brain targeted it first. This essentially explains the difference between UX and UI, since the two are eternally intermingled in the world of development.

As science continues to probe the depths of perception, it helps developers come up with more effective ways in which to present information in a way that enhances the user experience and the benefit of any given application to the user. However, in order to make any user interface change effective, you must apply it consistently across the entire application and ensure that the technique isn’t used to an extreme. Choosing just one element per display (whether a page, window, or dialog box) to change is important. Otherwise, the effectiveness of the technique is diluted and the user might not notice it at all.

What is your take on the use of perception as a means of controlling the user interface? Do you feel that subtle techniques like the ones described in this post are helpful? Let me know your thoughts at


Guessing At What Your User Wants Doesn’t Work

Web-based applications seem determined to embrace a form of automation that really doesn’t make a lot of sense and it’s causing more than a little woe for end users. Personalization, the act of guessing what a user wants based on previous activity, is a serious problem. At one level, personalization is actually costing vendors sales. For example, because of my previous searches on Amazon, I couldn’t find a product I really wanted. Amazon kept suggesting items I didn’t want or need. I ended up buying the product on another site and only later found I could purchase it on Amazon for less money. (Not to pick on Amazon too much, I have the same sorts of problems with other sites such as Google.)

Adding personalization to an application is supposed to help a user find items of interest, but we often need to search for something other than the usual item or may not even know what we want. In these situations, personalization actually gets in the way. A recent article, “Personalization is collapsing the Web” expresses the idea clearly by pointing out that people are sometimes ill-informed about current issues because personalization hides relevant news from view. The problem is so prevalent that it now has a name, the filter bubble, as described in “Content Personalization: How Much Is Too Much?” Users can’t find the information they need and vendors are losing sales due to the filter bubble created by various search engine vendors such as Microsoft (in Bing).

In order to provide personalization, sites must track your every move. It isn’t just the National Security Agency (NSA) that snoops on you, but just about everyone else on the Web as well. To some extent, any suggestion that you have any privacy on the Web is simply unrealistic. However, there comes a point at which the snooping, categorization, and misinformed suggestions get to the point of ridiculous and savvy users start searching for alternatives. One such alternative espoused by writers such as John Dvorak is DuckDuckGo. At least it doesn’t track your every move or provide you with suggestions that you don’t need. The prying can even take odd turns, such as the woman who was arrested for researching a pressure cooker on Google.

Guessing, even if the guessing is informed by previous activity, usually won’t work for an application. In fact, it’s probably a bad practice for a lot of reasons. Here are the things that you should consider when thinking about adding personalization to your application.


  • Guesses are usually wrong because few personalization engines can actually understand user needs successfully.
  • Personalization can cost an organization money by hiding products, services, or information that a user really needs.
  • Wrongful suggestions reduce the confidence the user has in the application.
  • Tracking the user makes the user feel spied upon.
  • Time and resources required to track a user and offer personalized suggestions could be better spent by making the application faster, more reliable, and more secure.

Odd as it might seen, I have never yet encountered a situation where personalization was an aid to anything other than making me leave the site for a location that isn’t personalized. When viewing a news site, it’s better to see the top stories of the day and drill down into the less sensational stories as needed. In most cases, what I really need is a good search engine that helps me find what I want, once I know what it is. Let me know your thoughts about personalization at


The Place of Automation in the User Interface

There was a time that a developer could rely on users to possess a certain level of technical acumen. That’s no longer the case. Most of the people using a device containing a CPU today (I’m including PCs, laptops, tablets, and smartphones here) don’t know anything about how it works and they don’t care to know either. All these people know is that they really must have access to their app. (Some don’t even realize the role data plays in making the app work.) The app can perform myriad tasks—everything from keeping track of the calories they’ve eaten to maintaining the scheduled events for the day. Devices that contain CPUs have become the irreplaceable partner for many people and these devices must work without much concern on the part of the user. In short, the device must provide a superior level of automation or the user simply won’t know how to interact with it.

I was recently watching television and saw a commercial for a Weight Watchers app for mobile devices. In the commercial, a woman exclaims wonder about the new programs that Weight Watchers provides, which include this app for her mobile devices. To track her calories, she simply points her phone at the box containing whatever food she plans to eat and the app tracks the calories for her. The interesting part is that there is no data entry required. As technology continues to progress, you can expect to see more apps of this type. People really don’t want to know anything about your app, how it works, or the cool code you put into it. They want to use the app without thinking about it at all.

Of all the parts of a device that must be automated, the user interface is most important and also the most difficult to create. Users really don’t want to have to think about the interface. Their focus is on the task that the app performs for them. In fact, some e-mails I’ve received recently about my Windows 8 book have driven home the idea that the app must simply work without any thought at all. It’s because of these e-mails (and those for other books I’ve written) that I wrote the article entitled, “Designing Apps with Automation in Mind.” This article points out the essential behaviors that applications must exhibit today to be successful.

On the other side of the fence, I continue to encounter an “old world” philosophy on the part of developers that applications should pack as much as possible into a small space—users will eventually figure out the complexity of the interface provided. Unfortunately, as users become more vocal in requiring IT to meet their demands, these approaches to the user interface will lose out. The next app is a click away and if it does the job of automating the interface better, your app will lose out. Even if there isn’t another app to use, the user will simply ignore the app you’ve provided. The user will rely on an older version or simply not interact with the app if there is no older version. Many organizations have found out the hard way that attempting to force users to interact with an app is bound to fail.

The fact is, to be successful today, a developer must be part psychologist, part graphics artist, and part programming genius. Creating an acceptable interface is no longer good enough, especially when people want to access the same app from more than one device. The interface must be simple, must work well, and must automate as much of the input as possible for the user or it simply won’t succeed. Let me know your thoughts about user interface automation at


Exciting Applications Mean Happy Users

At one time a developer could create a command line application with the most horrid and undocumented interface possible, and still get people to use it. That’s because the users were other geeks who loved the complexity of working with computer systems. For these users, part of the thrill of using a computer was the fact that it was hard to do. They saw the skill of using a computer as something that almost made them part of a secret society or possibly magicians of a sort. In fact, it was Arthur C. Clarke who stated, “Any sufficiently advanced technology is indistinguishable from magic.” Today, computers are no longer magic—they’re a well-understood commodity, and users are no longer geeks for the most part, they consist of everyone else who would rather view all technology with the same lack of attention as a light switch. In order to garner attention for your application, you must create usable interfaces that generate excitement—something that many developers have a hard time achieving and a topic that is sadly lacking from college courses.

That’s the reason I wrote, “Creating Excitement for Your Next Custom App.” Most developers can create interesting and useful applications that perform specific tasks, but they have a hard time making the application exciting because they can’t view things in the same way that the user does. This article provides simple techniques that you can use to make your next application a lot more exciting to end users. The focus of the article is to help you see things from the same perspective that your users do so that you can better relate to user needs and become a lot more successful in your development efforts with a lot less work.

We live in a world of extremely short attention spans, sound bites, constant stimulation, and people who have no desire to rack their brains thinking about anything. If you want to be a successful developer today, you really do need to generate the kind of attention that attracts users. It doesn’t matter how interesting your application is if no one tries it. In order to gain a following, you must first interest users in working with your application. Once a user sees how useful your application is, he/she will tell others and your application will become a success, but you won’t go anywhere without generating the needed excitement first. Let me know your thoughts about the article and techniques you use to generate excitement at


Exploring the TimeCheck Application (Part 14)

Today we’ll wrap up the discussion about frmConfigure. If you remember from the Exploring the TimeCheck Application (Part 13) post, we’ve finished up the major configuration controls, but there are three areas that you still need to know about:


  • Constructors
  • Form Loading
  • Form Closing

All three of these elements appear in this post. Let’s begin with the constructors. The application can either create frmConfigure by defining a blank form or by passing information needed to populate the form with data. The following code shows both of the constructors needed to fulfill these tasks:

// Create a variable to hold the user data.
public UserSettings UserData;
// Create a variable to hold the group data.
public GroupSettings GroupData;
public frmConfigure()
   // Perform the default configuration.
   // Check for the user data.
   if (UserData == null)
      // Initialize the user data.
      UserData = new UserSettings();
   // Check for the group data.
   if (GroupData == null)
      // Initialize the group data.
      GroupData = new GroupSettings();
   // Fill the administrator provided task and project lists.
public frmConfigure(UserSettings UserData, GroupSettings GroupData)
   // Perform the default configuration.
   // Check for the user data.
   if (UserData == null)
      // Initialize the user data.
      this.UserData = new UserSettings();
   // Otherwise, use the supplied settings.
      this.UserData = UserData;
   // Check for the group data.
   if (GroupData == null)
      // Initialize the group data.
      this.GroupData = new GroupSettings();
   // Otherwise, use the supplied settings.
      this.GroupData = GroupData;
   // Fill the administrator provided task and project lists.

In both cases, the constructor must create the UserData and GroupData local variables that you’ve seen used for so many purposes in the application. When the caller supplies the required data, frmConfigure uses it. Otherwise, frmConfigure creates new, blank variables that the application can fill with data. No matter how the data are supplied, the constructors call FillLists() to fill the user interface with data so that the user can see the settings (if any).

The form isn’t completely populated with data, nor is it stable at this point. The application raises the FormLoad() event at some point, which calls this event handler:

private void frmConfigure_Load(object sender, EventArgs e)
   // When there is user data to use, display it.
   if (UserData != null)
      // Configure the form fields.
      cbProjectName.SelectedText = UserData.DefaultProject;
      cbWorkType.SelectedText = UserData.DefaultTask;
      txtNetLocation.Text = UserData.NetworkPath;
      chkCustomProject.Checked = GroupData.CustomProject;
      chkCustomWork.Checked = GroupData.CustomTask;

At this point, the form is ready for the user to interact with. We’ll be looking at some additional code later to handle the requirements for working with administrators, versus standard users. For now, just consider that the form is ready to use. The user does whatever he/she needs to do, and then clicks either Cancel or OK to close the form. Now, some actions automatically save data because you simply don’t want to take a chance that the user will close the form in some other way and lose settings. However, it’s important to save the data one last time when the user clicks OK to ensure absolutely every change appears on disk. That’s the purpose of the two event handlers shown here.

private void btnCancel_Click(object sender, EventArgs e)
   // Close this dialog box.
private void btnOK_Click(object sender, EventArgs e)
   // Save the changes to the user data.
   if (cbProjectName.SelectedText != "")
      UserData.DefaultProject = cbProjectName.SelectedText;
   if (cbWorkType.SelectedText != "")
      UserData.DefaultTask = cbWorkType.SelectedText;
   UserData.NetworkPath = txtNetLocation.Text;
   // Save the changes to the group data.
   GroupData.CustomProject = chkCustomProject.Checked;
   GroupData.CustomTask = chkCustomWork.Checked;
   foreach (String Item in lstStandardProjects.Items)
      GroupData.ProjectList.Add(new Project(Item));
   foreach (String Item in lstStandardTasks.Items)
      GroupData.TaskList.Add(new Task(Item));
   // Close the dialog box.

As you can see, clicking Cancel simply closes the form. However, when you click OK, the application saves the data as it appears on screen. This is important because it’s possible that things could have gotten out of sync as the user interacted with the form. The result of the btnOK_Click() event handler is that the data on disk appears precisely the same as the user saw it on screen.

At this point, you have a basic frmConfigure completed. The next post will focus on the code used to make frmMain work. In the meantime, let me know if you have any questions about any of the frmConfigure code at


Rise of the Touch Interface

I’ve been reading quite a lot about touch interfaces as of late. It seems as if vendors are determined to force everyone down the road to using touch interfaces whether the interface makes sense for every application or not. Because Windows 8 is placing such a strong emphasis on the Metro Interface, which focuses strongly on using a touch screen, I’ve been spending quite a lot of time thinking about how touch interfaces will affect computer usage in the future.

Let me begin by saying that from everything I’ve seen, touch interfaces probably work well for many consumer applications. For example, if you want to take some photos of the kids and then make some modifications to them before sending them to someone else, a touch interface probably does the job. However, my thoughts generally focus on business applications and the business environment where people are working in front of desktop systems most of the day. The focus of this post is on how the rise of the touch interface will work in the business environment.

The first consideration I made was size constraints. Touch interfaces work exceptionally well with smaller, handheld devices. There are some people who say that desktop computers are going the way of the dinosaur and that everyone will be using a tablet device at some point. I’m not persuaded that this changeover is going to take place. Although people may use a tablet and/or cellphone in addition to a desktop system at work, desktop computers are abundant and will probably remain so for a number of practical reasons.


  • The desktop computer screen is large enough to see well and to use for complex applications.
  • A desktop computer can use multiple screens.
  • It’s hard to run off with a desktop computer (in other words, steal it).
  • Desktop computers are easy to upgrade and maintain.
  • A desktop computer can contain more hardware than smaller platforms (such as add-ins for scientific or industrial work).
  • Multiple users can easily use a single desktop system.

I’ve read all of the arguments for using a cellphone or tablet to perform every business task and I just don’t buy them. Some tasks simply require a larger platform. (For example, I can’t imagine writing a book using a cellphone; the very idea is ridiculous). Unless someone comes out with a magic desktop platform killer, I doubt very much that the desktop computer is going to simply disappear. Even if such a platform should appear tomorrow, the installed base of desktop systems in immense. Replacing them is going to take time.

So, why the focus on desktop systems? The answer is simple. Desktop systems don’t work well with touch interfaces. Until you rid the world of the desktop, you’re going to need to support the keyboard and mouse interface. Some vendors just don’t understand this basic concept and think that users will somehow feel comfortable reaching over their keyboard (and whatever else is on their desk) to touch a monitor screen. It just doesn’t make sense to me.

Let’s drop the desktop as an argument (partly because I can hear the hushed wind of many signs out there ). Even if you’re using a touch screen compatible device, there are going to be times when you want to type or you require more accuracy than a touch interface provides. Theoretically, this also means you’ll want to mouse about too. If the operating system isn’t friendly toward this sort of usage, the user is going to be less productive. More importantly, the user is going to become frustrated and use any other operating system that offers the flexibility that the user wants. For example, trying to draw anything detailed using a touch interface is nearly impossible (you really need a graphics tablet or a mouse to do that). Selecting things with fat fingers (such as the ones attached to my hands) is incredibly frustrating using a touch interface unless you’re talking about larger items (such as an entire icon).

The touch interface is here to stay. I can see how using a touch interface could speed certain tasks. Unfortunately, I can also see that using a touch interface exclusively will make certain tasks unnecessarily cumbersome and slow the user inordinately. As I work with various interface options, I see a touch interface as an addition to the current options, and not a replacement for them. What is your take on the touch interface? Have you used one? Have you used it to perform complex tasks without using any other sort of input device? I’d really appreciate getting your input on this topic at


The Ribbon in Windows 8

Windows 8 will include the Ribbon in a lot of places that you’ve never seen it before and it appears that Microsoft eventually plans to use the Ribbon everywhere it can. For developers, this means a major reworking of applications that have been stable for a long time. For users, it means learning a new way of doing things when the user hasn’t worked with a version of Office that includes the Ribbon. A blog entry by Preston Gralla put things into perspective for me. Even if you hate the Ribbon, you’ll have to use it in Windows 8.

In my book, C# Design and Development, I discuss the need to create a reliable user interface that works for every user who uses an application. A number of changes are occurring in Windows 8 that are going to prove interesting when viewed in the perspective of the user interface—who it serves best. Earlier versions of Windows are better suited for the power user because they provide a quick method of finding precisely what you need using toolbars and menus. However, novice users are often lost and sometimes can’t accomplish the required tasks at all.

RibbonX for Dummies describes how the Ribbon can simplify the user experience and even create a workflow environment for novice users. In fact, many of the examples in that book are based on workflows. I get into some examples of the Ribbon in the latest edition of VBA for Dummies, but not at the depth found in RibbonX for Dummies. The emphasis of these examples is to help you create a usable Ribbon interface in Office. The point is that the Ribbon is a useful interface for a particular group of usersmost likely the majority of Windows users who aren’t technically savvy. Many power users that I’ve talked with still view it as cumbersome and state emphatically that it slows them down. Managers I talk with are obviously most concerned about training costs associated with moving to the Ribbon.

Because the Ribbon has taken center place in Office, I’ve written a number of blog entries about it for VBA developers. I plan to continue covering the Ribbon for Office in the VBA for Dummies category. From what I’ve been reading in Steven Sinofky’s blog posts, it appears that at least some of the information I’m providing for VBA for Dummies readers will also apply to Windows 8 developers, but it isn’t clear yet at what level. However, I’ll keep tracking Windows 8 carefully and let you know how things start working out.

In the meantime, as a developer, you should start looking at applications outside of Office that use the Ribbon successfully. For example, you’ll find a good Ribbon experience in WinZip. Working with this user interface will likely provide ideas for a Ribbon for your own applications.

Of course, as an author, I’m constantly looking for reader input. How do you feel about the Ribbon? Do you think it’ll prove cumbersome or will it be a great benefit? What questions would you like answered in a user-level book about Windows 8 when it comes to the Ribbon? What would a developer need to know about it? Let me know your viewpoint at