Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Splitting a large UX into smaller components

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael1954
    replied
    Re: Splitting a large UX into smaller components

    Thanks Pete

    Leave a comment:


  • peteconway
    replied
    Re: Splitting a large UX into smaller components

    These Video's might help you..

    Video on some tricks.

    Video on background Images and opacity.

    Leave a comment:


  • Michael1954
    replied
    Re: Splitting a large UX into smaller components

    Hi, David I fully understand and agree.

    I had set myself the goal of making the connected web app have full functionality. The disconnected app was never going to have a mapping element. My agreed development route was to offer a number of "experiments" , an experiment can be less polished and just show the layout and functionality.

    The task I set myself was searchable "horizontals" with a full filter functionality. The "verticals" had no real meaning if there were not 4 750ml bottles of different years. This reduces the list to 500 lines. With verticals, it was worth having mapping and bottle labels just to give the page a little more interest.

    The client was not very interested in a dashboard, the wine is fairly static. Equally, he did not want to have a pretty landing page.

    One important function was to check the average and last price paid for a particular wine. This would generally be done on the iPhone 6.

    So as you can see a fairly simple application, the skin needs to be consistent across all devices whether offline or online.

    Producing a working app is say 40% of the project. It also needs to be fit for purpose in every use case. The last 40% is the UX/UI design and this is also causing me problems because of the way the French Laundry works.


    I am just sitting down to study Pete's video again.


    Thanks Guys.

    Leave a comment:


  • peteconway
    replied
    Re: Splitting a large UX into smaller components

    Well said David.

    Leave a comment:


  • Davidk
    replied
    Re: Splitting a large UX into smaller components

    If your goal is to create an app your client can use on a plane, disconnected, then that's what you should work on... and toward. As Pete shows, building a connected application that delivers 500 rows at a time is very responsive. 1 million, 2 million, doesn't really matter since the sql backend is doing the work responding to a request by Alpha for 500 rows. Whether it's the first page or last page of a million rows... you're asking for 500 rows... so it will always be fast. The search, as shown, is server-side, so if you're returning a small number of rows it's going to be fast as well.

    Overall, you have to be very, very specific about what your development goals and plans are... what you want to deliver... what you need to deliver. And then build toward those goals.

    You can't have a disconnected application and have 500 rows at a time as totally acceptable... the 2 don't go together.

    There are at least 4 disconnected, large data solutions available for Alpha including File System Storage via Alpha, SQLite and noSQL.
    Last edited by Davidk; 07-17-2016, 10:10 PM.

    Leave a comment:


  • peteconway
    replied
    Re: Splitting a large UX into smaller components

    It's very easy for things to get lost in translation in a product in constant revision ( a good thing ).

    Stick with it and you will get the rewards.

    Leave a comment:


  • GGandhi
    replied
    Re: Splitting a large UX into smaller components

    .removed
    may not be appropriate answer.
    Last edited by GGandhi; 07-17-2016, 07:52 AM.

    Leave a comment:


  • Michael1954
    replied
    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.

    Leave a comment:


  • peteconway
    replied
    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

    Leave a comment:


  • Michael1954
    replied
    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.

    Leave a comment:


  • peteconway
    replied
    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?

    Leave a comment:


  • GGandhi
    replied
    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).

    Leave a comment:


  • Davidk
    replied
    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.

    Leave a comment:


  • Michael1954
    replied
    Re: Splitting a large UX into smaller components

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

    Leave a comment:


  • Michael1954
    replied
    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.

    Leave a comment:

Working...
X