This commit is contained in:
@@ -14,13 +14,11 @@ TODO CLIENT STUFF
|
||||
|
||||
TODO NEXT
|
||||
|
||||
FORM MENU see down below, then other items in the list like feedback in save button when broken rules etc
|
||||
|
||||
Just put up latest build to server now...
|
||||
- Test on mobile and desktop all browsers before moving on, it must be solid with error handling (required, after before etc) and etc and then if all is well we can move on to the other field types
|
||||
MENU STUFF IN PROGRESS see down below
|
||||
|
||||
|
||||
TEST RESULTS
|
||||
|
||||
TEST RESULTS AND TODO
|
||||
|
||||
All platforms and browsers
|
||||
- IN PROGRESS: Initially outdated, had to force a refresh to make it load the latest version
|
||||
@@ -31,65 +29,46 @@ All platforms and browsers
|
||||
- IMPLEMENTED / NOT TESTED: Login, doesn't have any ui if failed login, maybe a red frowny face icon? :)
|
||||
- IMPLEMENTED / NOT TESTED: need clear buttons on pw and login
|
||||
- IMPLEMENTED / NOT TESTED: Numeric input fields don't give numeric keyboard
|
||||
- Navigation guard: navigate away with unsaved changes should warn and prevent but have option to continue anyway
|
||||
- Save on broken rules in Widget edit form it's not clear that save does nothing if there are broken rules. Button should be deactivated or there should be a message if you click on it or something.
|
||||
- Red outline and inactive seems ideal
|
||||
- Save button placement, not sure I like having to scroll down the page to save on small format screens where there is potentially going to be a *lot* of scrolling needed which hides the info box etc
|
||||
- How do modern apps do it?
|
||||
- MENU STUFF
|
||||
- DONE Global Help link on *every* page
|
||||
- will change on each page
|
||||
- DONE Global Logout link on every page
|
||||
- Unchanging
|
||||
- Probably more global page items
|
||||
- DONE Menu supports dividers
|
||||
- DONE Menu has a context section and a global section
|
||||
- One set of menu items only not two separate ones internally
|
||||
- Context items are at the top, then a divider, then the global ones at the bottom
|
||||
- DONE Caller sets if it's contextual or not to adapt colour of app bar, but otherwise it's the same exact menu all the time
|
||||
- DONE Caller should be able to set items colour so (for example) Save can be redded out when not savable
|
||||
- DONE Caller should be able to set the ENABLED property so it can handle different states
|
||||
- DONE: Maybe a change item event that takes a key and updates it rather than refreshing the whole menu basis on state change?
|
||||
- I.E. so that can change save button enabled and colour when state of form broken rules changes?
|
||||
- DONE Surface property that will force an item to be surfaced to the left of the menu in the app-bar
|
||||
- Keep the original in the menu though for people that are used to it?
|
||||
- DONE reorganize SAVE, DELETE ETC, put a divider between main form actions and then all the myriad of secondary things
|
||||
#### HERE -> LOCALIZE - check all new menu items, some might be not localized (look for ALL CAPS)
|
||||
- WIRE UP logout link to go to login form and logout properly
|
||||
- WIRE up save menu item and add code to disable save on broken rules (and make red, disabled etc)
|
||||
- Wire up delete menu item
|
||||
- Move ABOUT item to just above HELP in menu and remove from main NAV and make it navigate properly on click
|
||||
- DO I need to institute a back button? (in APP MODE?? installed to "desktop" on device will I be able to easily navigate without back and forward buttons)
|
||||
|
||||
- Navigation guard: navigate away with unsaved changes should warn and prevent but have option to continue anyway
|
||||
- Widget list, refresh page causes items per page to reset back to 5 from custom setting, it should cache that shit at least for a session anyway
|
||||
- Although people probably would want this to be saved to survive sessions
|
||||
- maybe it should save it per device locally only so that the customizations are local to the device so they can customize differently for different ui's?
|
||||
- Or, maybe they always want to see 50 widgets no matter where but 10 clients??
|
||||
- Edit form title, does the edit form need a title so users know where they are at?
|
||||
- DONE Edit form title, does the edit form need a title so users know where they are at?
|
||||
- currently widget edit doesn't have a particular look or title so if you are at the top of it on a small device you can't see the url fully or really know which page it is
|
||||
- A small title top left that stands out might be approprpiate, also a icon beside it?
|
||||
|
||||
- IMPLEMENTED / NOT TESTED: Application name is all lowercase "ayanova" when installed to device, must be something in the manifest files?
|
||||
- Check about page localization code, is it firing in the right place because on Edge and iPad firefox it didn't show localized at first until a refresh so it fetched the keys but didn't display properly
|
||||
- Calendar on iPad in two occasions with ff and opera the calendar date could not be selected until a time was changed then the date worked. Before that it would always stay the same no matter what selection was made and the UI would not show a change on select or press of date either.
|
||||
|
||||
- FORM MENU / NAVIGATION BAR / OVERFLOW MENU
|
||||
- According to official specs:
|
||||
- Nav bar should show where you are in the title part
|
||||
- Name of form or object in nav bar itself, possibly an icon also indicating the item in question?
|
||||
- It should change colour when in a sub screen and not the main screen with only a back button
|
||||
- I like being able to go anywhere any time from the navigation menu so I'm not sure I can support only a back button, but I can see having a back button
|
||||
- I like it changing colour to indicate it's become contextual in the overflow and options
|
||||
- So, when in any main view it's standard coloured but as soon as you're editing a record or in any form that demands a contextual menu item then it flips to black
|
||||
- It should have the most used features surfaced adn the least in an overflow 3 dots menu to the far right.
|
||||
- Search, save, whatever is most used on that form
|
||||
- As the screen gets smaller items progressively move into the overflow until, at the smallest they are all in the overflow
|
||||
- So what I'm reading is I should enable only one app bar at the top and morph it for states where appropriate
|
||||
- Try to make a menu in the top bar APP.VUE and if not then explore options inside the form
|
||||
- Is a fab appropriate for save and new the most common options??
|
||||
- See the best way to do this, either in the very top bar or in somethign in the page itself
|
||||
- Top bar is good because it's always visible even when at the bottom of a form, however it won't be actually inside the form itself so
|
||||
- If can connect to it via the form that would be excellent
|
||||
- for now make stub items similar to v7: Print, wiki, history, duplicate, delete, help
|
||||
- Make a 3 dots menu item that is contextual and appears at the top of any form in the shell interface??
|
||||
- Put the help option there since it's contextutal to whatever form is being displayed
|
||||
- Move help menu item in shell into menu as bottom item instead
|
||||
- TODO: CODE THIS FOR THIS MENU ISSUE
|
||||
- Just added ability to send info to store that is picked up by nav menu
|
||||
- REQUIREMENTS
|
||||
- DONE Global Help link on *every* page
|
||||
- will change on each page
|
||||
- DONE Global Logout link on every page
|
||||
- Unchanging
|
||||
- Probably more global page items
|
||||
- DONE Menu supports dividers
|
||||
- DONE Menu has a context section and a global section
|
||||
- One set of menu items only not two separate ones internally
|
||||
- Context items are at the top, then a divider, then the global ones at the bottom
|
||||
- DONE Caller sets if it's contextual or not to adapt colour of app bar, but otherwise it's the same exact menu all the time
|
||||
- DONE Caller should be able to set items colour so (for example) Save can be redded out when not savable
|
||||
- DONE Caller should be able to set the ENABLED property so it can handle different states
|
||||
- DONE: Maybe a change item event that takes a key and updates it rather than refreshing the whole menu basis on state change?
|
||||
- I.E. so that can change save button enabled and colour when state of form broken rules changes?
|
||||
- Surface property that will force an item to be surfaced to the left of the menu in the app-bar
|
||||
- Keep the original in the menu though for people that are used to it?
|
||||
- reorganize SAVE, DELETE ETC, put a divider between main form actions and then all the myriad of secondary things
|
||||
- On login, sometimes the home page is not showing as localized! Some kind of timing issue or wrong event used to localize it or something. ??
|
||||
|
||||
|
||||
|
||||
|
||||
iPad
|
||||
|
||||
@@ -22,8 +22,7 @@
|
||||
<v-toolbar-items>
|
||||
<template v-for="(item) in appBar.menuItems">
|
||||
<v-btn
|
||||
class="hidden-xs-only"
|
||||
right
|
||||
class="hidden-xs-only"
|
||||
icon
|
||||
v-if="item.surface"
|
||||
:key="item.key"
|
||||
@@ -36,7 +35,7 @@
|
||||
<v-spacer></v-spacer>
|
||||
<v-menu bottom left>
|
||||
<template v-slot:activator="{ on }">
|
||||
<v-btn flat dark icon v-on="on">
|
||||
<v-btn flat icon v-on="on">
|
||||
<v-icon>fa-ellipsis-v</v-icon>
|
||||
</v-btn>
|
||||
</template>
|
||||
|
||||
Reference in New Issue
Block a user