Monday, January 29, 2007

Lotusphere Demo: Enhancing A Template UI

My perfectionist tendencies usually keep me from posting things until I'm almost completely satisfied with them. However, since so many of you have been clamoring for the demos from Lotusphere, I'm going to start putting them here, even though they are far from perfect. First up is the remake of the Document Library template that I started working with on the plane down to Lotusphere. We showed this one really fast, so let me preface this with some quick background. Sitting in the airport, I was thinking about the idea that I bring up often regarding interfaces in Notes. Basically, I think you can really push the boundaries of what you have seen with the UI...you just have to be willing to put forth the effort. Sometimes, it's not really even that hard. By the time I got on the plane, I decided that I wanted to take a stab at modifying one of the default templates that Lotus provides us. I chose the standard Document Library.

Now don't get me wrong. I think the out of the box templates are very powerful and are a great way to get up and running with Notes. The user experience, however, leaves something to be desired. They worked great 10 years ago, but are now beginning to show their age. I specifically chose the Document Library because...ug...look at that color. Yikes! :-) In case you forgot, here's what it looks like populated with some documents.



I love the color scheme even more with the pink unread marks! :-D

Anyway, this isn't the worst Notes UI I've seen by far, but there is much improvement that can be made. I decided to model the new UI after a commercially available app, just so you could see how easily the UI can be tweaked to look like almost anything. I'm a big fan of the work the guys at 37signals do, so this updated Document Library is a homage to their Basecamp app. By the time we were in the air and laptops could be turned on, I had a rough idea of the changes to make. I fired up my machine and worked for the next couple of hours on the main layout. Since I returned from Lotusphere, I had a couple of ideas to tweak it a little more, adding in some neat functionality (although whether or not this would be practical in the real world would of course depend on user testing). After all is said and done, I ended up with something like this:



While I made a few underlying changes to the design, I tried mostly not to touch any of the existing things. Looks a bit nicer I think.

Alright...here's the database so you can open it up and play around with it. Again...I'll throw out the disclaimer that this isn't close to done, but if you had to wait until I felt comfortable with it, you'd be waiting a long time! :-)

I did come up with one cool new technique that I'd like to point out (new for me anyway). Check out the little "Abstract" box to the right of the view. I did this, of course, with an embedded editor/embedded view combo. I wanted to make sure, however, that only the abstract appeared in this box. Luckily, there is a hide-when property to hide information when it is embedded. This becomes problematic, unfortunately, when you have a rich-text field, since each paragraph of the rich text has it's own hide-when property. Another challenge I had here was that I wanted to format the abstract text in a particular way, with a fixed width and with a little gradient shading. I didn't want this to appear when the user opened the document though, but there's not an option to "show information only when embedded". After I thought about it for a little while, I remembered one of my favorite design elements...programmable tables!

To get the functionality I was looking for, I created a programmable table with 2 rows. The first row should be visible when the user opens the document for reading and editing. The second row contains the formatted abstract area and should only be visible when the document is embedded. Here's where a handy trick comes into play. In the PostOpen event of the "Document" form, I placed the following code:



Sub Postopen(Source As Notesuidocument)

Dim workspace As New NotesUIWorkspace
Dim uidoc As NotesUIDocument
Dim doc As NotesDocument

Set uidoc = workspace.CurrentDocument
If uidoc.Document.UniversalID <> Source.Document.UniversalID Then 'Doc is embedded editor
Set doc=Source.document
doc.~$AbstractTable = "Row2"
Call Source.RefreshHideFormulas
Call doc.removeitem("$AbstractTable")
End If

End Sub


This LotusScript was converted to HTML using the ls2html routine,
provided by Julian Robichaux at nsftools.com.


When a document is in an embedded editor, uidoc refers to the container document, while Source refers to the document that is embedded. If the document is opened and it is not embedded, then these two objects reference the same thing. So, I check the UNID and if they are different, I assume that the document is embedded and thus show "Row2" instead of "Row1". Pretty cool, eh?



There's probably some major deficiencies in this that I haven't encountered, but so far in playing around with it, it seems to work pretty well. In any event, the technique may have some useful applications in the future. Let me know your thoughts.

OK...I'll sign out for now. Enjoy playing around with the demo and feel free to share any comments or modifications that you've made. Note that I didn't make any changes to the form yet. That is a challenge unto itself. First I want to get some of the other things out there. The drag and drop demo is coming up tomorrow...keep an eye out for that. Cheers!

12 comments:

Richard said...

Great post. I've never seen a tabbed table in notes like that before...very cool. now the fun part of working it out :)

Ed said...

What's that sound that Homer Simpson makes when he sees a donut or a beer... ohhhhh, sweeeeeet.

Thanks Chris!

Michael Evans said...

It looks great. However it doesn't seem as usable as the standard template.
1) You've taken out what I would have thought was one of the most important features in a document library - the ability to search.
2) The size of the view is a lot smaller so you can't see as much in it without scrolling.
3) Putting the menu at the top can look nice but as soon as you need to add more views there's no space.
4) No way to create new documents (sure this was just an oversight :)

Nathan said...

Holy crap! The programmable tables trick is SWEET!

I'll give you the ever-so-minor pitfall on that: the source vs. workspace.uidocument difference also applies when surfacing in a dialog box. That's the only issue, and it's WAY minor.

Michael, adding a search interface to this is literally a checkbox click. The difference is view size is at least a matter of taste -- particularly if Chris refines this model to include search or other limiter tools (wasn't there a demo with author-as-combobox at 'sphere?)

Always remember that these are concept demos. As Chris says, there's zero user-testing on this.

Nathan said...

Actually, I might work on that layer interface later this morning. I have an interesting idea for presentation.

Chris Blatnick said...

@Michael...Thanks and you're correct on all points. This isn't supposed to be ready to use, but just to show you how things can look. As Nathan points out, search would be simple to add, as well as a link to create new docs. As we touched on in our session, the tabbed table metaphor is good for a limited number of tabs, so this obviously wouldn't be a good choice for a database with many views. In any case, try to look beyond these problems to see the potential of how the UI can be significantly changed with a little elbow grease! :-)

Chris Blatnick said...

@Nathan...Yep...the 'By Author' view and 'By Category' view have combobox filters. Not sure how practical this would be in real life, but it looks kind of cool! :-)

Michael Evans said...

Chris, sorry if it came cross negative. I realize it's a demo of what's possible and didn't mean to be to critical. I always enjoy your posts as I'm also interested in interface design and you have some great ideas.

Nathan, maybe I'm just being stupid but I didn't think it was possible to show the search bar on an embedded view?

Chris Blatnick said...

@Michael...No worries at all! You didn't come across as negative. I just wanted to make sure everyone knew this wasn't ready for prime time. :-) Thanks for the nice comments too! As far as searching goes, if I went with this setup, I'd probably just make my own search functionality placed up in the header area (where it says "logged in as...". Actually, if you can show a search bar on an embedded view, that would be news to me too. I'll have to check that out when I get to the office!

Corey said...

Hi Guys, I've come across the same issue with the search bar in embedded views. I have an app that opens to a dashboard view (which is actually a form in a 2 frame frameset). There are outlines that serve for navigation, and a main element that is an embedded view. The embedded view gets switched out based on the outline navigation. No big deal.

However, I've noticed that I cannot insert the search bar. I initially wanted to be able to let the user toggle it on and off, but that doesn't work. When I tried to just have it opened in the view, it doesn't work either. I'm in the process of trying to create a workaround by creating my own search box on the form, (similar to a web search box that shows up in the right hand navigation).

Chris, I've been inspired by the work that you are doing. Thanks for the great site!

Nathan, glad to see you aboard on all of this as well. You two make a great team!

Keep up the great work!

Chris Whisonant said...

Nice...

One thing I hope you can answer - when did Mike Portnoy learn to reveal the database design? ;) By the way, that's a cool tip!

Chris Blatnick said...

@Chris...LOL...Mike Portnoy is a man of many talents! :-D

Actually, all of those documents that are in there are from my personal document library where I store all kinds of tips and tricks...the majority of which I didn't come up with. :-)