If the Kiwix role isn't run common/assets/zim_version_idx.json isn't created. This leaves the menu hanging when accessed through the browser.

For the benefit of others who may be considering rewriting all or part of this repo without consulting its author and to record my thoughts, here are some ideas I hope to implement in the coming months.

A. Overall Look and Feel

The current use of bright colors, comic sans header, and treasure chest logo was aimed at school kids, especially in the primary grades. In fact the green background color was matched to the OLPC XO. As IIAB has moved beyond a school server to a medical reference appliance for users on smart phones this has become less than desired.

B. Menu Features for Desktop and Mobile

1. Support for multiple tabs
2. Configurable amount of detail or verbosity for menu items
3. Language selection similar to South Asia medical version
4. Dynamic menu rendering on front end including runtime substitutions for host and other parameters
5. A feedback mechanism

C. Add a distinct mobile layout with the following additional characteristics:

1. No logo
2. Just Internet in a Box text in header
3. Simple, modern font
4. Menu item logos to appear in circles, much like photos in many apps
5. Add a gear or 3 line icon to allow custom settings, like language, verbosity, etc. and perhaps access to help.

D. Menu Definitions

1. Currently the description is a single field. Add description 1, 2, 3 to allow for different amounts of text for different users. These should be separate paragraphs or other markup to discourage the need for adding spacing within fields.
2. Create conversion application to build new json definitions from current ones.
3. Verbosity may be set in menu.json, separately for desktop and mobile, and by individual users on mobile up to and including a minimal display of icon and title or just tile.
4. Add more substitution strings like ##HOST##, such as ##ARTICLES## - Number of articles in a zim and other parameters readable from content metadata to make it unnecesary to hard code these values in menu defintions.
5. Remove APK links from zim definitions and add separate item type for links to APKs.
6. Add new type for Kolibri.

E. Integration with Admin Console

1. Move array and other runtime parameters to an external json file, such as menu.json, that can be written by a management app.
2. Add ability to edit menu definitions via a form a la OER2GO.
3. Support limited rich text such as bolding, italics, etc.
4. Rework 'extra_html' to support links without html or minimally with some flavor of Markdown.
5. Try to eliminate html and definitely javascript from menu definitions.
6. Add ability to include and reorder menu items via a drag and drop form a la OER2GO.
7. Support versioning and local versions of definitions.
8. Automatically populate menu.json with references for downloaded or copied content.
9. Support showing the total disk space for items on a menu.

F. Future

1. Architect in such a way that it can be integrated with the Napster of Alexandria online catalog integration application.
2. Community contributed menu item lists
3. Community contributed menu definitions

Different types of menu defs are distinguished by the value of the intended_use property. The property name was selected to be in sync with Kiwix and the agreements regarding metadata, though I'm not sure anyone else uses it. The list of types has evolved and could now be extended and rationalized.

The purpose of this field to to tell the dynamic menuing system how to generated the link, so we need a unique value for each unique rule. The intention is to describe navigation in a generic way that holds true across deployments or at least those that follow our conventions.

We could also introduce a sub type, such that kiwix, kalite, etc are all 'service' with the name of the service as a sub type, but it adds complexity to both the json (for an editor) and the javascript (for a developer).

Calibre is installed on port 8080 but the config.json file directs Calibre to port 8010