Do users really use Views?! It's a question I've been asking myself more and more as the years go by, but it's a question I don't really know the definitive answer to.

The accepted approach whenever creating a Domino-based app is to stick in half a dozen or so views, each sorted by one or another primary field. Let's say it's an invoicing app to track invoices. You might have any of the following view and more: "by number", "by customer", "by value".

Do users want that though? To me it simply harks back to the days of Notes client app where the left hand navigation is simply made up of a set of links to different views.

It might work well enough in Notes, but does it translate to the web? The web is different to Notes, but it seems that we just try and mimic Notes apps in the above regard when webifying them.

Working as I do, remotely and isolated from end users, it's often hard to gauge how much a user uses or relies on what I give them. While it might seem acceptable to take a "no news is good news" stance, it doesn't mean the user is perfectly happy just because they haven't complained.

Over the last few years I've found myself questioning the usefulness of "Form X by Field Y" views. Especially those that contain 1,000s of documents and only show 30 at a time, with the obligatory "Next" / "Previous" navigation system at the bottom.

Surely users don't actually navigate through these views, page by page, looking for what they want, on a regular basis?!!

What's the alternative? I guess it's to give them quick and ready access to whatever it is they're actually looking for. This will vary for each application, but in most cases I'd guess they looking for one document in particular or a small subset of documents based on some criteria.

Either way what we should do is ask the users what their most common goals are and make it as easy as we can for them to accomplish them.

Over the coming days I plan on showing a couple of ways in which I think we can help. What I'll show are not perfect solutions by any means (but then nor are paginated views). They're just alternatives. One thing I want to show is an "infinite scrolling" view. The other is a "quick search" feature.

For now, it's open for discussion...

There are 24 comments in 17 threads Read - Add

Back in the days when I was a big fan of using Adobe Flex I remember one of the complaints against it was that the default look and feel (while quite nice) was always used and rarely changed, which made every single app look the same as the other. A bit like this:

My love of Flex waned. This was mainly because I realised that using it was becoming less and less viable, but also because, when Flex 4 came out, they tried to make it so that you had to customise the UI. I see where they were coming from but I didn't like it.

I've since become a fan of the next best thing, which is Bootstrap and is simply pure HTML and CSS.

The same arguments could be made of Bootstrap - that it's all too easy to make all the web apps you make look just like the last. A bit like this:

All very samey. And it's all too easy not to bother changing it. Although, luckily for us, if you choose to, then customising Bootstrap is a whole lot easier than they'd made it to customize Flex 4.

Because Bootstrap is just HTML and CSS you customise it in any way you like. If you don't feel that adventurous then there are loads of sites out there to help.

Wrap Bootstrap

Take a look at WrapBootstrap.com where there are plenty of skins to choose from and most look amazing. Of particular interest to us guys, I guess, is the "Admin and Dashboards" category. In no time at all you can throw together an amazing looking web app (based on Classic Domino if you wish).

Jetstrap

Once you've settled on a look and feel you can use a site like jetstrap.com to start combining the Bootstrap components on a page using drag and drop. Very cool and worth a look!

There are 8 comments in 5 threads Read - Add

487 Votes

In the comments to my post I wished I'd not posted about LotusScript last week, somebody wrote:

Quit trying to sell customers programs written in BASIC. You might as well be sending them documentation written with crayons.

While I agree in essence that it's doing customers no real long-term favours writing code in LotusScript, the choice over what to use (if there's a choice at all!) is rarely a simple one.

A few days later I posted another LotusScript-based entry. I expected no interest in it, but was pleasantly surprised how much interest there was. Makes me wonder if LotusScript really is a relic of a dead language.

Time for a survey.

Please open this entry in order to vote.

There are 27 comments in 18 threads Read - Add

I know LotusScript is a "legacy" language, but, some of us still use it on all-too-regular basis (myself included) to think of it that way.

Recently I devised a set of core LotusScript "wrapper" classes that help with some of the more mundane aspects of writing web apps built with LotusScript.

A lot of the LotusScript I've written over the years has been along the lines of something like this:

Dim coll as NotesDocumentCollection
Dim view as NotesView
Dim doc as NotesDocument

set view = database.GetView("InvoicesByUserName")
Set coll = view.GetAllDocumentsByKey("jake howlett", True)
Set doc = coll.GetFirstDocument()

Print "content-type: application/json"
Print "["
While not doc is Nothing
        Print |{"Title":"|+doc.getItemValue("Title")(0)+|", "Value": |+_ 
         Cstr(doc.GetItemValue("Value")(0))+|},|

        Set doc = coll.GetNextDocument(doc)
Wend
Print "]"

Nothing wrong with the code above (apart from one problem I've left in for the eagle eyed ÔÇô top marks to anybody who spots it!), per se, but imagine you could write it like this instead:

Dim factory As New InvoiceFactory()
Dim invoices As InvoiceCollection

Set invoices = factory.getAllInvociesForUser("jake howlett")

Print "content-type: application/json"

Call factory.PrintToWebAsJSONArray(invoices)

Well, now you can!

Not only that, but you can write code like this:

Dim factory As New InvoiceFactory
Dim invoices As InvoiceCollection
Dim invoice As Invoice

Set invoices = factory.GetAllInvoices()

If invoices.Count > 0 Then

 Set invoice = invoices.getFirst()

 While Not invoice Is Nothing

  Print "<h1>" + invoice.Title + "</h1><p>" + invoice.ValueFormattedAsString + "</p>"
  Print "<h4>As JSON</h4>"
  Print "<p><code>" + invoice.AsJSON + "</code></p>"

  Print "<h3>Customer</h3>"
  
  Print "<p>Customer's name is " + invoice.Customer.FullNameReversed +_
   " ("+ invoice.CustomerID + "), who has " +_
   CStr(invoice.Customer.Invoices.Count) + " invoices in total.</p>"
   
  Print "<h4>As JSON</h4>"
  Print "<p><code>" + invoice.Customer.AsJSON + "</code></p>"
 
  Print "<hr>"

  Set invoice = invoices.getNext()

 Wend
End If

The custom classes in use above are InvoiceFactory, InvoiceCollection and Invoice. They are based, respectfully, on the base classes DocumentFactory, DocumentCollection and DocumentWrapper.

These three base classes can be used to represent each type of business object in the database. Roughly speaking, there's one set of classes per Form used. The above three classes are for the Invoice form. Each Invoice is linked to a customer, which has a Customer form and can be represented using the CustomerFactory, CustomerCollection and Customer classes.

All the code involved is available here.

The benefits of using classes to represent objects should go without saying. It just makes things so much simpler. Not only to maintain, but also to code. Instead of typing: document.getItemValue("DidICallTheTitleFieldTitle?")(0) you just type invoice.Title (Domino Designer even suggests this for you as you type!).

You no longer need to litter your LotusScript agents with field names and logic. I know field names rarely change, but you never know! The benefits of class-based logic stretch way further than that.

Using this approach requires quite a bit of upfront work to set the classes up, but it's worth it. If not just for that warm fuzzy feeling of seeing your classes and properties appear while type-ahead coding. No? That's just me then is it?

All a bit late in the day really. I so wish I'd come up with this approach 10 years ago....

Is there any interest in this? I'm guessing not, but if there is I can put together a demo download.

There are 25 comments in 12 threads Read - Add

The danger in LotusScript is when you spend time in other "proper" languages and then return to LotusScript, foolishly thinking you can use what you use elsewhere.

Take this as an example:

Dim i As Integer

For i = 1 to 2

   Dim isIAnOddNumber As Boolean 'Defaults to False!
        
   If i Mod 2 = 1 Then
       isIAnOddNumber = True
   End If

   Print isIAnOddNumber
Next

What would you expect the output to be?

There are 35 comments in 10 threads Read - Add