The winds of change are blowing here at Interface Matters and in my opinion are way, way overdue. The only excuse I have is lack of time to devote to these changes (or at least lack of desire to devote the time since other things have been occupying my attention of late). I have been wanting to make some changes here for quite some time, and as the new year rolls around, it's probably as good a time as any to make the leap.
First, I want Interface Matters to expand beyond a single voice. This has always been my plan and I have just failed to execute. This site was never designed to be my personal blog. If it had been, I would have called it chrisblatnick.com. This is the reason I've tried to limit the amount of personal content and why more posts are article length rather than quick blurbs. My original vision was that this site would serve as a good resource for UI ideas for Lotus Notes developers, something that could be referred to now and again like a well-worn book on your shelf. Although I check traffic very, very infrequently, the notifications I get on occasion show me that people are still downloading the sample databases, so there must be at least some value here. The last couple of years have been light on content in this space, though, since I am not doing day-to-day development anymore. This brings me to the first change.
I'm looking to expand the authorship of Interface Matters and I'm looking to you out there in the Lotus community to help me. I believe there is a lot of richness and value in getting multiple viewpoints on user interface and user experience concepts, and I'd love for this to be the place to get it. There are many innovations happening in the collaborative development space lately and along with these new technologies (e.g. XPages), there are new design and interface challenges. I hope we don't fall into the same trap we did with Notes client apps and make every XPage look exactly like OneUI. I hope these other voices are out there and ready to step up and share with the rest of us. So, the concept is simple. If you have an idea for an article that would fit the mission of Interface Matters and you would like to have it posted here, just send me an e-mail and we'll put it on the map. For now, I'll maintain editorial duties and will still contribute too, but I'd definitely love to open Interface Matters up to more contributors. I've tested the waters a bit in the past with a guest author or two and think it works quite nicely.
That brings me to the second change. I would finally like to move this blog to the Domino platform. I originally started using Blogger because I wanted to explore what other blog engines were out there and Blogger was one of the most popular. I never changed because quite frankly it is so simple to use, but along with this move to mutliple contributors, I'd like to finally design a decent looking blog template. To do so, I need to ask a couple of questions:
1. Any suggestions for Domino hosting?
2. I might open up the design to someone that wants to tackle it. Hmmm...perhaps a contest? Any thoughts?
I really do hope to hear from some of you. I think this site has more potential that it's been showing lately and these updates might just be the thing to spice it up a bit.
With that, I'll sign off and wish you all a fantastic holiday season!
I've always been a fan of performing tasks as efficiently as possible and eliminating the drudgery of those tasks that don't add a lot of value to my work or personal life. One of those tasks which is a necessary evil is the maintenance of paper-based documents. Everyone has them...bills that need to be paid, bank statements, tax documents, owner's manuals, receipts. As much as possible, many of us have tried to digitize these things so we don't receive them as paper in the first place. I've pretty much successfully eliminated any kind of bill coming to me in the mail and have turned every monthly payment into an automated one. Technology is a great enabler for managing a lot of this "stuff", but if you are like me, you probably have a legacy of paper filed away in some part of your house. For me, my paper legacy takes the form of two file cabinets full of the paperwork that makes up my life since I started college. A great majority of the paper is content that I will never likely have to revisit, but feel the need to keep in case it is required for some reason. Financial and legal documents seem to be the most prevalent in this category. In the 10 years I've been in my current house, I've never had to go to the file cabinet and physically pull my mortgage papers, yet there they are, taking up valuable space and stuffing the drawer so it makes it harder to get to the stuff I really do need to see. Earlier in the year, I decided to start tackling the paper problem in my house. Ironically, as a collaboration architect working with Lotus technologies, I've helped many companies eliminate paper from business processes through the years, but never really took action on it in my own life. The cobbler's children and all...
Anyway, in order to get rid of paper, I knew that I would have to digitize it and then store it in such a way as to find it as easily as I could find information in my physical file cabinet. To do this, I would need a scanner. Now I've had a flat-bed scanner for many years, but I understood from using it that it was in no way up to the task of digitizing my life. The process of individually putting each page of a document on the bed would be far too cumbersome to manage in a timely fashion. No...what I needed was a scanner than provided a paper-feed mechanism and that could handle paper fast. From doing research over the years, I had one and only one device in mind and the only reason I hadn't pulled the trigger yet was cost. That device was the Fujitsu ScanSnap and let me tell you, it is the best money I have ever spent on a piece of computer hardware, bar none. My only regret was not having picked this thing up sooner. To do it justice, I don't just want to explain the ScanSnap, I want to show it to you. More on that in a minute.
So I recognized a problem: too much paper. That was the first step. Now I needed to make an actionable plan to deal with it. That's where the ScanSnap came in. I started using it to scan papers in when they came in the mail. As soon as I came across something I needed to keep (my monthly bank statement, for instance), I digitized it and stored it on my hard drive and then shredded the document. Ah...a great feeling. I've been doing this for several months now and it has been very successful. However, nagging at the back of my mind (even though it was on my Someday/Maybe GTD list) was the massive task of tackling those file cabinets. Over the Thanksgiving break, I finally took the plunge and mapped out my paper processing workflow. This is my first attempt at the process, and I'm sure it will be enhanced and refined over time. In any case, based on a couple of e-mails I received in regards to my tweets about "Operation: Paperless Office", I thought I would share a video with you on how I am doing this. This also gives me a chance to showcase the Fujitsu ScanSnap, which I think is just a phenomenal device!
First up, here is a brief note I made when I was thinking through the process. (Yes...I believe in the power of prototyping and visual rendering even when I'm not doing application development!).
It turns out that so far this is working nicely. The following videos describe the ScanSnap functionality and show you my paper processing workflow in action. A couple of notes about the videos. First, I have a face for radio and a voice for print, so try to ignore the narrator and focus on the content. Second, I used my son's Flip video for this rather than my hi-def camcorder. I was kind of giving the Flip a trial run to test some things out and after going through the entire process, I thought it flowed pretty well and I was afraid if I tried to re-record it to be more "professional" then it would just come off feeling scripted and contrived. What you get here is me just trying to describe the process as if I was talking with you face to face. Take that as you will. :-)
As you'll see if you check out the videos, another important component of my paper processing workflow is Dropbox. This service is an excellent way to replicate data across systems and functions as a temporary to permanent backup system. With it, I feel comfortable knowing that I can destroy a document as soon as the ScanSnap captures it. Dropbox provides a free and premium service. Check out their website to learn more and get started with a free account. If you use my referral link, you'll get an additional 250 MB of space on top of the 2 GB they give you for free (so will I...thanks!).
If you have questions or suggestions, I'd love to hear them. Cheers!
Forgive Them...For They Know Not What They Do...With Your App
If you've been following along with the home game, then you are aware that there are many excellent UI patterns that you can use to improve the user experience you deliver to your users in your applications. Today, I wanted to explore another simple yet powerful pattern: "Forgiving Formats". This pattern is perfect for those applications in which speed to data entry is key (or at least desirable in most circumstances). I know in many of the business applications I have encountered over the years, we tend to develop nice, complex forms to capture all of the data the customer says they absolutely need. When you come back and look at the database later, however, you often find that only a few key fields are filled out (just the required ones if you're using validation!). The Forgiving Format pattern is all about letting users enter those key bits of data quickly, without having to worry overly much about the way they are entering the content. This pattern puts the onus on you as the developer to do the heavy lifting, not the end user. Of course, this is one of the tenants of interface first design. It allows you to simplify the UI and make the problem really about the behind-the-scenes code.
A great example of the Forgiving Format pattern is Google Maps. When searching for an address, you can use a variety of inputs. For example, when searching for a location in my town, I can put in:
Aurora Aurora, OH Aurora, Ohio 44202 etc.
This flexibility allows me to focus on the job at hand, not on the exact way I have to format the address so that Google understands it. This lets me get my work done faster, so obviously it makes me a happy user.
You can apply this same idea to your applications. I find it can be useful both for allowing quick data entry for Notes documents as well as for use as a search mechanism. The underlying idea is simple. As the developer, you have to account for the various input types the user may enter and then code for those instances. In my Movie Review sample database, the main input is obviously movie information. While the form allows you to capture more data, there are only a few fields that are key to building a good database of movie knowledge. These include the movie title, the rating, the genre and the running time. I created a Quick Movie Entry option in the database to show this in action. First, let's take a look at how I implemented this.
I created a caption in the frame so that the user could free up screen real estate if they didn't want to use this option. It gets it out of the way if the user will be doing something other than data entry. However, if they want to quickly add a bunch of movies, they can expand the caption area and then will see an input line for the movie information. Of course you could break the input into a bunch of separate fields to capture the user input, but a single field is easier and more elegant.
I included a brief explanation of what the user should enter with this control. This particular pattern works best when you have information that is targeted to a specific objective and when the input is something that you can prepare for. Leaving it completely open ended would be incredibly hard to program for and would likely result in failure. In this case, I'm expecting those four particular bits of data and I want the user to enter them in that order, as specified by the help text. When you choose to implement this functionality in your own application, you will have to weigh how flexible you want to be with the input field and possible combinations of entries vs. the complexity of the evaluating code.
In the Movie Review example, the user can enter the title, rating, genre and running time and then hit the "Go" button. If the code successfully recognizes the entry, a new document is created in the database and the user is informed via a popup message (using the fade in/fade out technique). If the input can't be recognized, the user sees an error message.
As far as the backend code goes, it can be fairly simple or very complex, depending again on how flexible you want to make this functionality for the end user. In this example, there are two fields that I'm actually mapping to already established categories. The rating should obviously be a valid entry (G, PG, PG-13, R and NC-17) and the genre has values such as Science Fiction, Drama, Comedy, etc. To evaluate these, I used a Select Case statement. This allows for the "forgiving" part of this pattern.
In the case of the rating, one user might enter a NC-17 movie as NC17 while another might use X and another might use XXX. They could also use varying values of upper and lower case (e.g. Nc17, nc-17, xxx). For each of these different possibilities, a Select Case statement makes it nice and easy to evaluate the input. I did the same thing with the genres. For a Disney movie, users might enter options like cartoon, animated, animation, etc.
Below is the sample code behind the button. Feel free to use this as a guide, but remember there is no robust error handling in the example.
Sub Click(Source As Button)
Dim workspace As New NotesUIWorkspace Dim session As New NotesSession Dim db As NotesDatabase Dim uidoc As NotesUIDocument Dim movieDoc As NotesDocument Dim entryDoc As NotesDocument Dim movieEntry As Variant
Set db = session.CurrentDatabase Set uidoc = workspace.CurrentDocument Set entryDoc = uidoc.Document
On Error Goto ShowError
movieEntry = entryDoc.MovieEntry
'Here's where you are going to do the meat of your work. 'You need to determine just how much logic you want to put 'in place to decode what the user has entered. I've given a 'couple of simple examples below.
Set movieDoc = db.CreateDocument movieDoc.Form = "Movie Review"
'Let's deal with the title first Dim movieTitle As String movieTitle = Strconv(movieEntry(0), 3)
'Rating Select Case movieEntry(1) Case "G", "g": movieRated = "G" Case "PG", "pg": movieRated = "PG" Case "PG13", "PG-13", "pg13", "pg-13": movieRated = "PG13" Case "R", "r": movieRated = "R" Case "NC17", "NC-17", "X", "XXX", "nc17", "nc-17", "x", "xxx": movieRated = "NC17" Case Else movieRated = "" End Select
'Category Select Case movieEntry(2) Case "Science Fiction", "scifi", "sci-fi", "SciFi", "Sci-Fi", "Sci-fi", "Scifi": Category = "Science Fiction" Case "Action", "action", "Adventure", "adventure": Category = "Action" Case "Comedy", "comedy", "funny", "Funny", "humor", "Humor": Category = "Comedy" Case "cartoon", "cartoon", "animation", "Animation", "animated", "Animated": Category = "Animation" 'etc, etc.... Case Else Category = "" End Select
'Here you'd actually perform the task (such as creating the 'new document if everything validated correctly. It should 'if you are careful with your forgiving format. If movieTitle <> "" And movieRated <> "" And Category <> "" Then Dim newMovie As NotesDocument Set newMovie = db.CreateDocument newMovie.Form = "Movie Review" newMovie.MovieTitle = movieTitle newMovie.Category = Category newMovie.MovieRated = movieRated newMovie.MovieTime = movieEntry(3) Call newMovie.Save(True, False)
'Display cool fade-in success message here Else ShowError: 'Display cool fade-in error message here End If Exit Sub
This LotusScript was converted to HTML using the ls2html routine, provided by Julian Robichaux at nsftools.com.
When you break it down, I think that this a very simple UI pattern to implement in your applications. As always, it comes down to trying to simplify the user's task. While this pattern is not applicable to all situations, I can think of a good number of Notes applications I use frequently that could benefit from the Forgiving Format pattern. Does one of yours? Give it a try and let me know how it goes.
Thoughts about Collaborative Technologies and User Interface Design...
By day, I work as a Collaborative Technologies
architect and champion the cause of usability and user interface design. But don't judge me
by my blog...I'm using a template. Cobbler's children and all... ;-)