Splitting a large UX into smaller components

[Michael1954]

Has anyone split a UX (iPad) to make it quicker to load and easier to manage?


I have a fairly simple program.

It shows 6,500 lines of wine data.

I allow filtering on this list.

I use 4 Layouts (templates) on the list data



These shots show the main screen.

MB Home screen.pngMB Popup.pngMB SB Home.png


I use a window container to display a modal with extra details. Currently, multiple lines are displayed using a list,
I have also written the code to build a table.

There is side menu that has a tree control, I build the JSON on the server. Above


Vertical has 2 lists a map and it displays an image. Below


MB Vertical.pngMB Vertical 1 Main.png

The filter uses server-side filtering and I allow the user the option of saving the filter choices to a database for future use.

[Michael1954]

Re: Splitting a large UX into smaller components

Continued

MB Vertical detail.png


Images of filtering

MB Filter.pngMB Alpha Filter.png


Any suggestions on the architecture and methods would be a great help.

The client will view this on a top end iPad

Later I want to build a control to save choices and export to excel.

[Michael1954]

Re: Splitting a large UX into smaller components

I also have a problem if I try to display an icon in the list. It slows rendering dramatically.

MB Layout templates.png



Sorry to split one question over 3 pages.

[peteconway]

Re: Splitting a large UX into smaller components

I'd say there's nothing wrong with your UX - but there sounds like something is wrong with your List, have your turned on Virtualization|Dynamic - normally when things run slow it's because the List is loading all the data. You could also try Pagination settings with auto callback. Also is the detail list set as a child of the parent?

[Davidk]

Re: Splitting a large UX into smaller components

I'd say it's impossible to tell if anything is wrong with anything without actually looking at it.

What Alpha version/build are you working with (funny how almost know one reports that). PhoneGap Build App? Web App?

Are you loading all Lists with all data on startup? Are some Lists set to render later? Is the data fluid? Do you need to load it from the server? Or is the data a bit more static and can be bundled with the app... if it is a PhoneGap Build app.

Do you really need access to 6500 wines on startup? Is someone really going to troll through a list of 6500 rows? If not... why load 6500 rows of data?

Quicker to load and easier to manage can be 2 opposing issues. Breaking the app up using embedded components makes development and debugging a joy. You get to work with one piece at a time. But... those embedded components need to be loaded at some point. Startup will be faster (if that's how you set things up)... but... then... when you need to access whatever is in the embedded components you'll wait a bit. It's a trade off.

If you're using PhoneGap Build you can pre-load all the data using SQLite. Very fast.

Overall... remember that you're working with the DOM (and if PhoneGap Build... a WebView). So... you're loading 6500 rows into the DOM along with all their associated divs and spans and etc., etc., etc. Thousands and thousands of lines of code created and managed.

[peteconway]

Re: Splitting a large UX into smaller components

Michael watch this video http://www.ajaxvideotutorials.com/V1...zationDemo.swf

[Michael1954]

Re: Splitting a large UX into smaller components

David

We have lots of Alpha licenses. Both old and subscription. The displayed app is 2999/4519. There is no problem changing to the latest build.

The data changes once a week. We download this data from a server with no API.

We do not load list until requested, with the exception of the main 6661-row list. This list is dynamically virtualised loading 50 records.

I am not sure if the client is going to flick through 6,500 rows. The problem is his brief, he asks for a list he can flick through. The reason we have built the filters is to reduce the list size. He has 1,500 US cabinet Sauvignon and 1,100 Burgundy wines. The storage company does not give a huge number of columns to filter these two groups.

When you have that number of unique wines it is a problem to remember each row.


"Overall... remember that you're working with the DOM (and if PhoneGap Build... a WebView). So... you're loading 6500 rows into the DOM along with all their associated divs and spans and etc., etc., etc. Thousands and thousands of lines of code created and managed."

This is really where I am struggling. I need to understand these tradeoffs to have a meaningful discussion with the client.

The client wants to be anywhere with three key presses.

He is used to restaurant wine apps and wants the same. Unfortunately, restaurants have limited wine lists so the styling and speed relate to a smaller simpler data set.

Peter

I have the boys playing with pagination and virtualisation but my brief is to mimic "The French Laundry" wine list. This list scrolls quickly and there is no pagination.

[Michael1954]

Re: Splitting a large UX into smaller components

Any ideas on the issue of icons slowing the load dramatically?

[Davidk]

Re: Splitting a large UX into smaller components

Really depends on the size of the icons... what they are... how they're being loaded... and from where.

So if only 1 list... the wine list is being loaded at startup... and with only 50 records... I wonder where the app is slow. Where is the server? What is the server?

2999 is quite old. There have been major improvements to how the List behaves since then. A Viewbox might be really helpful.

Realistically, I can't see anyone wanting to scroll through a list of 6500 rows. If they're wine people, they know what they're looking for... they're not just wandering. I would offer the full list as an option with a message that we're about to load 6500 wines... hold on a sec.

We still don't know if this is a web app or PhoneGap Build app.

[GGandhi]

Re: Splitting a large UX into smaller components

I have the boys playing with pagination and virtualisation but my brief is to mimic "The French Laundry" wine list. This list scrolls quickly and there is no pagination.

michael
i was curious and looked into the french laundry wine and spirits list, it is a sourced list from binwise and it does nothing but lists the names of the wines or spirits with their matching price. the list is prebuilt with the data from the french laundry and showed via the click of the link.
your alpha list is lot more versatile and functional, it won't be easy to mimic that list with alpha list and detail view with more information as i understand what the lists are in version 12.
however if your customer just wants to see the list of 6000 and some wines list without needing to do anything with it you may be able to build an a5w page with the data and place the a5w page in the dialog/ux an as embedded object. i am sure that will be faster than what alpha needs to fashion all the javascript things, css things to the list and load it in the ux. ( remember just a hello world ux takes about 700-800 lines of code )
there are also some javascript functionality called infinite scrolling, it is quite possible alpha virtual scrolling is that, i don't know just guessing. that is definitely an useful function to explore.
just my 2 cents in a world of unknown(version 12).

[peteconway]

Re: Splitting a large UX into smaller components

SO are the images on the Alpha Server or S3, is the list data bound, does it have a detail view, is the map real or an image?
If the answers are mages on AA Server and List is bound with a detail view then that's the issue.
So what is the config?

[Michael1954]

Re: Splitting a large UX into smaller components

Gandi

The french Laundry list is an app. I think they also have a list on the website bit I am not sure. Your idea of building my own display is worth investigating. I still need a complex filter.


Pete,

I am talking about font awesome icons. I think the mistake I am making is serving them conditionally. The icons that are served from the database are quick. Currently, the wine label images are causing no problem, the parent list is small just 400 lines but I display one record at a time after the user clicks on a list row. We will store the images on a CDN. I currently use no detail view.


David

Background on the client and list there are 31,000 bottles of wine with a value of $4,000,000; 6,500 lines displays the quantity of unique wines he owns. In this list a change in bottle size or year adds a line. There 6,661 rows if we also consider location. The client is going to flick through the list like reading a magazine.

Use cases I know of

Check the price paid for a wine. Simple filter. (This functionality will be in phone gap and is the only functionality required on the phone) .
Check verticals (Wines of the same name but different years)
Build a regular horizontal tasting. (compare French Bordeaux to Californian Bordeaux blend)
See where there are holes! in the collection. This can only be done by browsing.
Check which wines he is no longer collecting and build a disposal list.

Currently, we are building a proof of concept as a web app. The ultimate aim is to wrap it in PhoneGap as offline is advantageous. Most of the clients available free time is when traveling on a plane.

I see the client 4 times a year and as we are good friends, I am not allowed to talk app all of the time. I just present an "experiment" and we refine the functionality.

I take your point that the browse list may not be the best home page. My idea is for the client to save filters and set the default filter. This will allow him to save a search and return to this default when he returns next time.
If he works in this way then the filtered list will be 200 - 400 lines.

[peteconway]

Re: Splitting a large UX into smaller components

Michael we could banging on about this for days as we don't know the ins and outs of your UX, but watch this video and you will see your 6500 records should be no issue at all for Alpha, just re think your logic.

Play the Video Here.

Cheers Pete

[Michael1954]

Re: Splitting a large UX into smaller components

Pete thanks for that.

I think the first issue is using an old version of Alpha as David suggested.

Some of the functionality is not available in my build, I will use the latest production build and follow your example because what you have shown is totally acceptable.

I am sure I need to rethink my logic. The pointers I have got from people should get me to where I want to be. The beauty of the message board is that we all come at problems from slightly different angle.

Thanks I will play with this and report back.

[GGandhi]

Re: Splitting a large UX into smaller components

.removed
may not be appropriate answer.