CoreBOSBB

Full Version: My 2 cents from being a user in stead of a developer
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Since the company I maintain a coreBOS installation for lost an employee who in turn took over from me once, I am spending the majority of september filling in for him untill his permanent replacement arrives. That means that in stead of being a coreBOS developer, I am back to being a user for a month. That means I have a unique chance to experience and learn where coreBOS can improve from a 'regular' user standpoint. In stead of my personal coreBOS installation, where I only keep track of my own handful of customers, invoices and time control records, I now work with an installation that has been in use for 7 years, holds over 2.000 accounts, 10.000 SalesOrders and many more records of other types.

One of the first things that really pop out is that we need a better way to visually organize data. This means not only switching to LDS. LDS will make us prettier, not smarter. Sure, some things will stand out more due to a better use of colours but if we don't change the way we present data we won't be making any real changes. As someone who knows the system pretty well, I found myself opening many tabs when handling a single case file and losing track of what I was looking at pretty fast. And that's me, I know the system. Imagine someone that is not as well introduced into the system as I am.

So one of the first things that come to mind is a system for master detail presentation. Joe and I have talked about this many times, we have a draft of a Business Map and some prototyping on an implementation for InventoryDetails. I think we should start there and continue to build, make it modular, flexible and extendable. In the end we should be able to present a lot of data on a single page without confusing the user.

Something else that came to mind while contemplating master-detail was the number of levels. Master-detail implies two. You can view and edit a detail records from the view of the master record. But sometimes (more often than you would expect) you would need some access (maybe read only) to a record on a third level. Opening this record on the master record as a master-detail-detail view would (I think) be an overkill and would drown the user in information. But what if we could 'sidebar' it? With that I mean, open a record on a third, or even a deeper level using a narrow sidebar in a responsive vertical view. All this while still maintaining to be in the master record. Screens today have a tendency to be 16:9, or even wider. I think we have the room to do this without cluttering the main record (and the first detail level). Call this a 'sneak preview sidebar' if you will.

Whatever we do, I think we should focus on presenting the user with a lot of data in a single screen while still remaining clear what data you are looking at.

To that end, I think we should have some more visual aids in separating modules. Right now at a glance, it all looks pretty much the same. Which is good for consistency in the UI, and minimalizes our efforts to template, but also prohibits you from quickly knowing what you're looking at instinctively. I think we should do something about that too. On separate tabs, but also in future master-detail views and/or possible other views, like the sidebar I proposed. That could mean colors, icons and so on. Just anything that's both nice to look at and crystal clear.

These are my 2 cents at this point in time from being a user in stead of a developer, trying to fill in the blind spots we develop next to our code. Please feel free to comment, criticize and add.
very useful. thanks
As a reminder to self:

I think I will create a PR where related lists get a new button that will open the record in a new window in a 'preview' mode.
Do you mean that when you click on the link that takes you to the detail view, you want it to open by default in another tab?

If so, I personally click using the center mouse wheel, in most operating system if you click on a link using the center button (wheel) the link opens in a new tab. If you don't want to teach all your users this very useful functionality you can use the

Application_OpenRecordInNewXOnListView
Application_OpenRecordInNewXOnRelatedList

global variables to set that behavior
What you describe is the approach I use now yes. It's also the behaviour I teach new users. But I find it is not the best UX experience.

Most often, when you do this, you want to have some information about a related of detail record to be able to make some decision in the main record you are editing. The two-tab option is not ideal, since you basically just want to have the info you need to make a decision all in one screen. What I wanted to do is provide a simple read-only template that shows you the information without all the bells and whistles. At first I wanted to build my own 'window', but I then realized that this wouldn't support multiple screens, which I and many people I know that use coreBOS use.

So now I think I'll create some basic view-only template that you can open in a separate, smaller browser window. An example is this: when we perform visits to customers, we create a salesorder that represents that visit. A lot of times, that visit involves multiple helpdesk tickets that are in turn related to multiple assets. So when you're creating the salesorder you'd need to prepare it with for instance the correct inventory lines or some other data. Switching back and forth between 2 or 3 tickets, maybe an asset of two and the salesorder in creation becomes confusing and tedious quite fast when done in tabs.

So what if you could have some small windows on your second screen that would offer you the information you need regarding the assets and helpdesk tickets? I think that would benefit your workflow.

This is only one example but I think it could be applicable to many business cases and workflows. It's all about the presentation of data and customizing that presentation in a way that the user can work efficiëntly and with the least room for error.
I understand. We have used the tooltip functionality in the past to do this. As you probably know you can select fields to be shown in a small popup div of the record you are hovering over. We have added useful contextual information to that popup for some clients that need more information

Maybe we could create a business map that defines more information to show in the tooltip. Or a business map to completely override the current tooltip for some other widget more capable of holding and showing structured information

https://www.lightningdesignsystem.com/co...ts/modals/
https://www.lightningdesignsystem.com/co...ts/panels/
https://www.lightningdesignsystem.com/co.../popovers/
https://www.lightningdesignsystem.com/co.../tooltips/
Yeah tooltips crossed my mind as well and they do a better job at a sneak-peak, but still you need some mouse-action and can't 'peak' into multiple records at once. I would opt for the LDS panel but still open it in a real browser window. I'd rather use the LDS UI without the OS-window wrapped around that but I do strongly feel that a multi-screen support is crucial, so that kind of forces us in that direction. The panel's closing X could still function to close the window though.

In my proposed solution where would be no interaction other that to close the window and some responsive design (so that you can organize the data in the size that suits your needs), but responsive is baked into LDS so that's kind of a given. The only other functionality would be to quick-copy field contents I think. Or maybe a drag-n-drop, but I don't know how that behaves across multiple windows. I imagine some kind of 'I want to drag the info in this field to the input on my main record' kind of way.
I agree.

Copy paste is really easy, especially now that the library is loaded by default. Depending on what you want to drag it may just work. I just dragged some text into this box from another window and it worked.
That is very nice. Let's build something and see how it works out of the box...
Another note to self: we should clearly distiguish the entity identifier links in both list and related view so that a user knows which links to click to actually go to that record. Right now, I see a lot of users that for instance click a product name in a list of assets and end up at the product in stead of in the asset they expected to end up on.
Pages: 1 2