Redevelopment Plans

[tim-moody]

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

[psiie]

To prevent bloat I would recommend a build process. So we can work high level in whatever we want (the latest javascript uses const and let instead of var for example) and always have it compile down to compatible formats.

Why is this good? I accidentally used Object.assign at work and broke code. Who knew this came out in 2009 and IE8 wouldn't support it?! I didn't. It's hard to keep track of what supports what. Not to mention that working in newer Javascript gives us more "Intellisense" in the code editors (lets us know if variables are reassigned, data types, ect). Using a build process takes care of this for us. (I will happily make the build process. I've done it a few times now).

---

who may be considering rewriting all or part of this repo without consulting its author
You know, I've considered taking a shot at this but would need to figure out a development setup. I don't want to be working on VIM on a Pi Environment. Only thing stopping me :P.

I would recommend doing it over in React or some other MVC (model, view, controller). It lets you write code in a clean, high level, file/folder organized way that allows for infinite expansion. Thats why Facebook uses (invented) React.

They do produce flat files btw. Something that Apache can serve :).

---

Try to eliminate html and definitely javascript from menu definitions

Im totally on board with making the menu definitions better. I noticed that we have HTML in the extra_html part of the json files. It would be nice if we made a structure to adhere to that didn't require this. Or at the very least, we could use a markup language like Creole http://wikicreole.org/wiki/Creole1.0

Using markup would be sanitized by the rendering engine (such as React) and would inherently forbid security flaws.

---

Add new type for Kolibri

Totally down. I'm not a big fan on how diverse each content type is. I guess that's how the cookie crumbles.

I had an idea about a couple of weeks ago to unify content packs (for the distribution aspect and/or internal) but couldn't figure out a PoC. I was trying to mimic TinyCoreLinux's approach. You see, their manual claims that everything lives in a squashFS file and is merge mounted to /. So each compressed squashFS can mimic any filesystem inside in any structure needed. Then when mounted just merges with the OS and is treated as unzipped files.

Amazing right? Well mixed results ensued. I felt like this would have been a great end result for content packs that had to be distributed (as that is what you are gaining in benefit here; a single file (and compression too)). One file for complex file/folder directories. I can talk about the mixed results if this is worth going down. Things like OSM tiles may have immediate benefit.

---

Just some thoughts. Didn't mention design; I'm not far-flung either way. (But we need a logo Adam!)

[georgejhunt]

Progress Report

1. I think E.1 is done -- well maybe not, I don't know what other runtime parameters are wanted. And the js code I wrote is trying to mimic the js interpreter rather than a json.parser. It accepts "//" and assumes that the minuitem.json is really only a snippet from old index.html -- PR#11
2. I have a solution for E.6 "Add ability to include and reorder menu items", but it's a work in progress, and it does not use drag-n-drop. It will drop in a new "menuitems.json alongside "index.html".
3. I'm a week away from E.2 Add ability to edit menu definitions
4. Once Iiab menu js #3 is complete, D.1 and D.2 will be easy.
5. If we support editing menuitems, are we on the path to E.7? -- (local versions would be json items we write to iiab-menu/menu-files/local/). Maybe I don't understand. Do we want versioning across sites within a server, or deployments? Is this related to the tabs issue -- B.1?

[holta]

See also @georgejhunt's #11 & @tim-moody's new branch...PR imminent: https://github.com/tim-moody/iiab-admin-console/tree/js-menu-dec-1

[holta]

@tim-moody new PR: iiab/iiab-admin-console#95

[tim-moody]

Status:

B. Menu Features for Desktop and Mobile

Complete except for:

1. Support for multiple tabs - stubbed in but not implemented

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

Complete except for:

4. Menu item logos to appear in circles, much like photos in many apps - ? not needed
5. Add a gear or 3 line icon to allow custom settings, like language, verbosity, etc. and perhaps access to help. - language done, not verbosity

D. Menu Definitions

Complete except for:

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. - partially done in update menu script

E. Integration with Admin Console

Complete except for:

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. Support versioning and local versions of definitions.
7. Support showing the total disk space for items on a menu.