Quantcast

Ensuring that blank-state has been handled in UIs?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Ensuring that blank-state has been handled in UIs?

Saurabh Nanda
Hi Everyone,

In most user-interfaces we need special-treatment for blank states (zero-item state). For example:

* In case there are no customers, don't show an empty table, instead show the message "You seem to have no customers, why not start by creating one..."
* In case there are no bookings, don't show an empty table, instead show the message, "No bookings here. Want to create one?"
* In case there are no search results, don't show an empty table, instead show the message, "No items found. Undo your last filter?"

In some cases, the one-item case also needs special treatment, but I'm unable to come with relatable examples at the moment.

A lot of times the dev simply forgets about the blank state, and it is caught during QA, which results in a quick-fix on the following lines:

    if length item > 0 then displayTable else showBlankState
    if Data.Map.Strict.size map > 0 then displayTable else showBlankState
    if Data.Set.Ordered.size set > 0 then displayTable else showBlankState

Is there a way to prevent this bug from the get-go? Can we use the type-system (or anything else) to enforce the dev to at least _think_ about the blank state? Obviously, the type system can't help us with _what_ needs to be done with the blank state, but at least it can _remind_ the dev at compile-time about handling blank states.

-- Saurabh.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ensuring that blank-state has been handled in UIs?

Tomas Carnecky
Make your 'displayTable' function take a 'NonEmpty a' instead of a List (eg. [a] or Vector a). That at least ensures that you won't ever be showing an empty table. I don't think there is a Map/Set-equivalent of NonEmpty. But you will have to convert a Map/Set into a list at some point, and that's where you can again use NonEmpty.


On Sun, Apr 16, 2017 at 1:54 PM Saurabh Nanda <[hidden email]> wrote:
Hi Everyone,

In most user-interfaces we need special-treatment for blank states (zero-item state). For example:

* In case there are no customers, don't show an empty table, instead show the message "You seem to have no customers, why not start by creating one..."
* In case there are no bookings, don't show an empty table, instead show the message, "No bookings here. Want to create one?"
* In case there are no search results, don't show an empty table, instead show the message, "No items found. Undo your last filter?"

In some cases, the one-item case also needs special treatment, but I'm unable to come with relatable examples at the moment.

A lot of times the dev simply forgets about the blank state, and it is caught during QA, which results in a quick-fix on the following lines:

    if length item > 0 then displayTable else showBlankState
    if Data.Map.Strict.size map > 0 then displayTable else showBlankState
    if Data.Set.Ordered.size set > 0 then displayTable else showBlankState

Is there a way to prevent this bug from the get-go? Can we use the type-system (or anything else) to enforce the dev to at least _think_ about the blank state? Obviously, the type system can't help us with _what_ needs to be done with the blank state, but at least it can _remind_ the dev at compile-time about handling blank states.

-- Saurabh.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ensuring that blank-state has been handled in UIs?

MarLinn
In reply to this post by Saurabh Nanda
On 2017-04-16 13:51, Saurabh Nanda wrote:
> Can we use the type-system (or anything else) to enforce the dev to at
> least _think_ about the blank state?

That is an interesting problem. But I'd say the solution depends highly
on your architecture. Tomas' suggestion to use NonEmpty could be one
solution, and one you could try to build upon to track more details in
the types. Alternatively, you could add a typeclass that just handles
the zero-element-case. That way your constraints remind the developer to
at least copy-paste a default implementation.

        showItemTable :: (HasZeroItemPresentation (presenter item)) => presenter item -> [item] -> Table item

But maybe there's a much simpler solution: Create a datatype that stores
the normal presentation function, a zero-case presentation function, and
optionally a one-item presentation function. Now whenever someone
creates a new type of item, they need a new presentation adapter.

        data TablePresenter item = TablePresenter { showZeroItems :: Widget; showItem :: item -> Widget; showSingleItem :: Maybe (item -> Widget) }

        showItemTable :: TablePresenter item -> [item] -> Table item

This should offer safety and code reuse, and it should be easy to
integrate because you don't even have to start with types. Why be fancy
when the simple solutions work?

Cheers,
MarLinn
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ensuring that blank-state has been handled in UIs?

Mario Rogic
I think you might find the RemoteData solution here relevant to your problem: http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html

I've been using it successfully for a lot of UI work. Even if you have a default handler function that gives a sane-ish default value for the context you'll be using it in (I.e "Loading..." in UI), I've found it helps keep interfaces sane even when you "forget" you actually care about the empty state.


On Sun, 16 Apr 2017 at 15:07, MarLinn <[hidden email]> wrote:
On 2017-04-16 13:51, Saurabh Nanda wrote:
> Can we use the type-system (or anything else) to enforce the dev to at
> least _think_ about the blank state?

That is an interesting problem. But I'd say the solution depends highly
on your architecture. Tomas' suggestion to use NonEmpty could be one
solution, and one you could try to build upon to track more details in
the types. Alternatively, you could add a typeclass that just handles
the zero-element-case. That way your constraints remind the developer to
at least copy-paste a default implementation.

        showItemTable :: (HasZeroItemPresentation (presenter item)) => presenter item -> [item] -> Table item

But maybe there's a much simpler solution: Create a datatype that stores
the normal presentation function, a zero-case presentation function, and
optionally a one-item presentation function. Now whenever someone
creates a new type of item, they need a new presentation adapter.

        data TablePresenter item = TablePresenter { showZeroItems :: Widget; showItem :: item -> Widget; showSingleItem :: Maybe (item -> Widget) }

        showItemTable :: TablePresenter item -> [item] -> Table item

This should offer safety and code reuse, and it should be easy to
integrate because you don't even have to start with types. Why be fancy
when the simple solutions work?

Cheers,
MarLinn
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
--
- Mario

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Loading...