Add a GUI

[mjordan]

Part of MIK's flexibility is due to the fact that it's a command-line app..... but it would be interesting to see if a basic GUI could be added using something like http://wxphp.org/.

[mjordan]

Another approach would be to provide a slick tool for creating MIK configuration files. Maybe http://electron.atom.io/ would be worth looking into. Or for that matter, maybe an Atom package would suffice for creating .ini files.

[MarcusBarnes]

A GUI would especially be useful if one is using MIK as part of normal digitazation workflows. Some users are uncomfortable editing .ini files. The GUI could allow the creation of .ini files for some defined collection types (e.g., newspapers) based on known local-configurations of MIK (after set-up by someone with more technical knowledge). The GUI could also set off processing, including quality control checks or add jobs to a queue for later processing (e.g., for regular cron-like jobs).

[mjordan]

Another option for a GUI is to create a simple web a app in SIlex or Slim and run it locally using PHP's built-in web server (php -S localhost:8000, started with operating-system specific shortcut scripts that would appear on the user's desktop). Some tasks we could build into such a web app to provide more user-friendly tool than a command-line script could include:

• create and validate .ini files
• create mappings files using a web form
• generate mappings files from an existing MODS file

Potentially long-running tasks, like validating ingest packages or running preflight checks on input data, or performing MIK migrations/conversions themselves, would likely need to remain as command-line jobs, but providing a more friendly way to create .ini files and validate them, and mappings files, would result in a huge step forward in usability.

[mjordan]

Although apparently, ini_set('max_execution_time', 0); will let the web server run indefinitely, so we could even perform long-running MIK migration/conversion jobs using a local web server.

[mjordan]

Just occurred to me that a Drupal module would be a convenient GUI framework. The module would not be required to run MIK, it would just provide some helper tools for creating mappings and .ini files, for example, SFU could run one on behalf of the Islandora community, or sites could install it themselves if they wanted. I might try a proof of concept of this over the holidays.

[mjordan]

Inspired by @terrywbrady's talk at Code4libBC, perhaps an AppScript is another approach. https://github.com/terrywbrady/UsingAppScript

[mjordan]

@MarcusBarnes and @bondjimbond Can you take a look at this proof of concept "starter" MIK mappings tool? It's a Google spreadsheet that lets users choose a target snippet from a controlled list. It also contains a "Move to Islandora Kit" menu that provides a function to check the current snippet (i.e. where the cursor is) for syntax errors. The error messages returned by this function are coming directly from AppsScript's xml class and are not much more useful than other DOM parser messages, however.

https://docs.google.com/spreadsheets/d/1zbiBZ8s4AUk0Q8bSinMjuKBw0KFmqM6uf54YRScZN_g/copy?usp=sharing

When you access this link, you are asked to make a copy of the spreadsheet. Google may ask for some basic permissions to copy it to your Gdocs. One neat thing about this approach is that you can edit the snippet list. It's available in the "Snippet_library" tab in the copied spreadsheet.

End-user instructions for this tool would be something like:

1. Click on the link.
2. When prompted to make a copy of the "MIK mappings file template", do so. You may be prompted to by some the authorization requests before you can make a copy.
3. Wait until the small yellow "Working..." message disappears. You now have your own copy of the template that you can use to create your mappings file.
4. Add your first source field in the first cell in the A column.
5. In column B, type a MODS element name, or click on the down-pointing arrow to see a list of available MODS snippets. Choose the one you want.
6. If desired, modify the snippet. If you modify a snippet:
   • Google Sheets will indicate that you have a validation error because your snippet will no longer match an item from the list. A red triangle will appear in the upper-right corner of the cell, and you will see the message "Input must fall within the specified range". This is OK, it just indicates that your snippet is not in the controlled list.
   • You can check the syntax of the your modified snippet by opening the "Move to Islandora Kit" menu in Google Sheets and choosing the "Check snippet syntax" command.
7. Once you have created your mappings, export them as a CSV file:
   1. open the Google Sheets' "File" menu
   2. select "Download as...."
   3. choose "Comma-separated values"
8. The downloaded file can be used as your MIK mappings file. You can also edit if if you wish before using it.

[mjordan]

Working on a basic configuration file template generator as well.

[MarcusBarnes]

@mjordan Tested and works as you described. Would it be possible to get some feedback from non-programmers - maybe metadata librarians who might be tasked with creating the mappings for migrations? I know Google Sheets would likely be familiar to those working collaboratively on metadata issues, so this approach would definitely be helpful for that audience. Thanks @mjordan for this proof-of-concept. I'm looking forward to seeing where this goes.

[mjordan]

@MarcusBarnes thanks for taking a look. Perhaps members of the Islandora Metadata IG could offer some feedback. I'm happy to reach out to them to ask.

[MarcusBarnes]

@mjordan Excellent idea regarding reaching out to members of the Islandora Metadata IG.

[mjordan]

End user documentation, with screen shots, is at https://github.com/MarcusBarnes/mik/wiki/Metadata-Mappings-Helper.

[mjordan]

... and code for the Apps Script that adds the menu in Sheets and that checks the XML snippet syntax is at https://github.com/mjordan/mik_mappings_helper.

[bondjimbond]

That's a pretty nice basic mapping-maker. Probably doesn't need to be much fancier than that.

[mjordan]

We've been getting some positive feedback from early testers... any objection to linking to the Helper's documentation from https://github.com/MarcusBarnes/mik/wiki/The-mappings-file, maybe adding a brief cookbook entry pointing to the Helper, and updating the main README to remove the reference to "tools for creating mappings files"?

I assume we'll want to leave this issue open since it's more general than the problem the Helper addresses.

[MarcusBarnes]

@mjordan No objections since it appears to help some users. Thank you.

[mjordan]

Done. Cookbook entry is at https://github.com/MarcusBarnes/mik/wiki/Cookbook:-Using-the-Metadata-Mappings-Helper.

[mjordan]

Oh man we need a GUI for creating .ini files (and creating/validating mappings, etc.). Would love to see a desktop app written in https://electron.atom.io/ if we had resources.

[MarcusBarnes]

@mjordan https://electron.atom.io/ looks promising. I may investigate as it may prove useful for wrapping other work for cross-platform desktop usage. Thank you.

[mjordan]

It does look good. But, desktop apps have their own liabilities, like the fact that someone (in some cases, IT) needs to install them. As an alternative to a desktop app, HTML5 offers a lot of interactive features that we might use. That way, we could provide a web page that generates .ini files.

But, in terms of lowering the barrier to using MIK, there might be some other things we can do. For example:

• 107 and #352, and #353

• a script that a user could run that tested whether MIK was installed properly, using canned input data
• an interactive .ini file generator that asked questions like "Are you using metadata from a CSV file? (y/n)", etc.
  • This is, I know, a command-line operation. :frowning: