Changes between Version 9 and Version 10 of BluePrint/Menu
- 07/18/11 15:13:03 (12 years ago)
v9 v10 1 1 = Menu = 2 2 3 The current 3 menu system should be migrated to a single menu to take upo less screen real estate & provide a consistent UI experience. 3 Our current menu has these deficiencies: 4 * No visual clue to the user as to where in the system that they are 5 * Not easy to provide deployment customisations which are separated from the main code 6 7 Proposed solution: 8 * Move all the menu configuration to a single pair of files: 9 * Generic settings (01_menu.py) 10 * aURL handles the disabling of modules & hiding options without access rights 11 * deployment-template for per-instance customisation (01_menu_.py) 12 * Labels & Hiding unused options 13 * Render out HTML using a new S3Menu class (replacing the existing MENUS3) 14 * HTML/CSS will come from a design company 15 * 1st level navigation will be horizontal (as-now) with CSS to show which one we're active in 16 * 2nd level navigation will be available onHover of the 1st-level & when inside a 1st/2nd level, will be available as a vertical menu on the left 17 * 3rd level navigation will be available onHover of the 2nd-level & when inside a 3rd level, will be available as a submenu within the 2nd-level vertical menu on the left 18 * Breadcrumbs will be rendered out from the same configuration 19 * (default) Module index pages will be rendered out from the same configuration 20 * Site Map can be rendered out from the same configuration 4 21 5 22 Ideally this would be loaded once & then cached (e.g. have the system generate a static menu.js which can then be loaded/cached) … … 21 38 Ideas for improving the menu: 22 39 * Code for the menus should be segregated between the technical implementation and the layout - making it easy for non-technical users to customize the menu and reducing the clutter in the code, and reduce the amount of code being executed every run in the models. 23 * Define the customization of the menu in CSV? 24 40 * Make Menu customization completely independent from the modules. 25 41 * How many levels? Configurable. Suggestion. 26 * Application - a deployment sof Sahana may contain different applications, which may be used by different people and certainly at different times/workflows. This could be separate from the main menu - at the very top. 42 * Application - a deployment of Sahana may contain different applications, which may be used by different people and certainly at different times/workflows. This could be separate from the main menu - at the very top. 27 43 * Functional - what does someone want to do in the current application. 28 44 * Functional level 2 / Work Stage - this could represent work flow, or just reduce the clutter in one level of functional 29 45 * Avoid 3rd level - especially pop-ups! 30 * Breadcrumbs 31 * Allow modules to be turned on/off and also excluded from releases of code with simple switches. 32 * Allow the menu to indicate which option has been clicked (flag to set a class in the li - where set flag?). 33 46 34 47 Allow the user to define a custom home page, without editing core code.