Settings Option To Switch User Interface

[brianw-area24]

I would like to make it easier for WordPress users to use the new tsml-ui frontend. As an alternative to using a shortcode on a page, I'd like to have a setting on the Import & Settings page where the user could switch back and forth between tsml-ui, and the plugin's legacy interface.

Then on the archive-meetings page, it would check which frontend is chosen. If tsml-ui is chosen, it would simply output the top widget code, next it would output the code generated by the shortcode, and lastly, it would output the bottom widget code.

This would be a good next step in encouraging people to use tsml-ui. For now, the default behavior would be to use the legacy UI, therefore new sites would use legacy for now. However, we may want to change this up sometime in the future...

[Grateful-Viv]

If I may add a few comments here, I like the idea of using the TSML UI as the front end once it’s ready, but would like to keep the plug-in front end for an easier way to find and edit meetings for the admin. Using the meeting dashboard is not the easiest way to find the meetings to edit. It can only sort by meeting name, day and time. Yes, can do a search, but it’s so much faster to go to the plug-in front end to find the meeting you’re looking for.

As far as the widgets you mention, are you suggesting they could work with the UI, such as the html for Meeting Top, Meeting Detail Bottom?

[joshreisner]

I think it should default to use the latest TSML UI, but allow the user to select another version, which can be gotten from here:

https://data.jsdelivr.com/v1/package/gh/code4recovery/tsml-ui

default: https://cdn.jsdelivr.net/gh/code4recovery/tsml-ui/public/app.js

versioned: https://cdn.jsdelivr.net/gh/code4recovery/[email protected]/public/app.js

[brianw-area24]

Yes, I was thinking a selection of 3 options for now, of course the wording could change

1. TSML Plugin - legacy
2. TSML UI - beta
3. TSML UI - stable

[joshreisner]

That might be simpler than what I had in mind with listing out the version numbers, but that could work too.

[kiyote33]

@code4recovery/tsml-maintainers Is anyone actively working on this issue to facilitate local admins choosing which front-end interface their website uses? If not I'm comfortable picking it up. Let me know...

[kiyote33]

Additional notes from 2/26 bi-weekly:
Incorporating TSML UI into TSML - Issue #368
Five steps to adoption:

1. TSML default, TSML UI hidden
2. TSML default, TSML UI option
3. TSML UI default, TSML option
4. TSML UI default, TSML hidden
5. TSML UI default, TSML removed
   Permalinks eg /meetings/my-meeting-name need to redirect
   /meetings should be in the same place
   Google maps users warnings

[kiyote33]

@joshreisner Do you foresee TSML_UI supporting Google Maps, or is there a reason it can't support Google?

[joshreisner]

@kiyote33 i don't think TSML UI will ever support google maps. adding another map provider would make the javascript bundle too big

[kiyote33]

OK. I'll work with that...

[kiyote33]

Refactor Settings & Import admin page. Create tabs for Settings, Import/Export, Email Addresses, Mapping, and a default Welcome tab with content on getting help and Code For Recovery...

[kiyote33]

With the ability for local admins to be able to toggle between TSML and TSML UI, it would be nice to have both a Mapbox token and/or Google key, if they are available. Is there any reason we shouldn't allow it?

[joshreisner]

just seems like it could add unnecessary complexity. if you are using the TSML frontend and have both google maps and mapbox keys entered, which option will the interface choose?

[kiyote33]

Hopefully the first one that works. In my dev environment, mapbox works for TSML UI but not TSML. It's the reverse for Google, where Google works well for TSML but not TSML UI. When thinking of the end users, they may find it a little frustrating to have to change the mapping key every time they want to experiment with the new UI.

[joshreisner]

Hm, but Mapbox works fine for TSML - here's an example: https://aaboston.org/meetings/first-things-first-2

[kiyote33]

"A picture is worth a thousand words...", so a preview of the refactored Settings. Any thoughts or suggestions?

[joshreisner]

looks really good! the information density is very different on the import / export vs other pages. to my eye, the import / export looks like it fits the browser better. so my recommendations would be:

1. only have two pages, and make them both top level. so the left sidebar would read:

• meetings
• add new
• regions
• districts
• import / export
• settings

2. with two pages you would not need the tabs anymore (although nice job using wordpress's native tabs here!)
3. on the settings page, i would have all the descriptions be expanded (so they don't need to be collapsible anymore)
4. don't need the "12 step meeting list settings" title
5. move the logo inside the about box
6. are we ready to drop the "feed sharing" option entirely?
7. settings page could be three columns, like the import / export page is

[kiyote33]

Thanks for the quick response @joshreisner. For simplicity, I do prefer the tabbed approach. But I like your 3 column suggestion for "Settings", which would roll the email and mapping sections onto that tab. I'm in alignment on expanding the descriptions where possible. Same with moving the logo inside the about box. I'll move in that direction if that's good with everyone...

[joshreisner]

Ok thanks @kiyote33 ! I don't feel strongly, but the reason I suggested a single navigation menu is that I know there are sites that only update their meetings by reimporting. So having two navigation steps adds some friction for them to get to that screen.

You may also then want to keep the left menu option "Import & Settings" so they know they need to click there to get to the import screen.

[kiyote33]

I think we are on the same page, although I was thinking Two tabs with the default on Settings. Could put the default on Import Export, or maybe add a setting so the admin can pick the default. Of course, once we do something like that then they will want every little item to be configurable, so better we select the default and go with that.

[kiyote33]

Revision #2 - Two Tab Preview defaulting to the Import Export tab


Questions/Suggestions???

[joshreisner]

Changes look great thanks!

There's a little bit of a hierarchy problem on the fields now, due to my suggestion about removing the collapsible details. It's fine with me if you want to return to the way it was, or otherwise I think we should try to visually regroup the info. One way you might do this:

• bold the titles, eg "Distance Units"
• reduce space between the title and description to, idk, 10px? 8px? and between description and field to about the same or slightly less?
• add space between the bottom of the field and the next field (maybe about 20px?)

Maybe also make the tab Import / Export or Import & Export?

[tech2serve]

"Mapping" gets renamed to "Mapping and Geocoding"?

[kiyote33]

Revision #3 Review - Settings Tab Section Rendering. No change to Import / Export tab.

As usual, feedback is welcome!

[joshreisner]

i think it would look more consistent to try without the gray rounded rects - i think you could just use margins to group the fields with their titles and descriptions.

[kiyote33]

Rev #3b - How's this...

[joshreisner]

the problem is not that they were rounded. it’s that they’re not standard to wordpress or our other ui screens. they add some extra visual clutter and reduce text contrast.

like i wrote above, i think it would look cleaner to just try to adjust margins between elements

[kiyote33]

Rev #4b with borders turned on?

[kiyote33]

Rev #4c - feels like we may be getting closer. Keep your input coming...

[joshreisner]

@kiyote33 ❤️ ✨

[97eighty]

Looking good @kiyote33

[kiyote33]

REV 5 - Final Review. Thanks for all the input on this. Looks like this is pretty much the way it will look:

[kiyote33]

I'm looking for feedback on the Mapping & Geocoding. Does this make sense or do I revert to what we had yesterday. Please put your 2 cents worth in...

which expands to this...

[joshreisner]

i liked it better yesterday 👍

[tech2serve]

I just addressed another user's issue with setting up a site without having created a function mapping key. Anything we can do to improve their setup process is good imo.

[joshreisner]

@tech2serve i believe wayne shared a screencap of this somewhere recently, but if a user has no map key entered they get a gigantic message on the settings page telling them all about it. so i think from a settings-page-perspective we're already doing all we can (@kiyote33 sounds like we want to preserve this behavior in the new design).

on the meeting edit page, we also show them a message like this:

on the actual public UI we hide the maps on the detail page and on the list / map toggle

[tech2serve]

I understand, and yet we still have issues (relatively frequently) with users not understanding what it is they need to do or maintain for the mapping to work.

So, I support expansions and info buttons that help explain it to them. I do like the note showing on the map, and I'd hope that would help as well.

I am not crazy about the extra clutter from the expansion arrow, so perhaps a hover window instead?

[kiyote33]

From Slack:
I would like to suggest a Content compromise on this which I think considers a bit from all the stated views:

1. Start with the suggested Rev 5 layout version and content from 2 days ago (which got approval from everyone), but make the following content modifications.
2. Replace General Program description text reading "This selection determines which meeting types are available" to read "Select the Recovery Program your site targets here". Having an end user select a program based on their knowledge of what meeting types are available to each program is not the message we want here.
3. Replace General Meeting/Group Contacts Are heading with Contact Visibility.
4. Keep the new Feed Management section heading.
5. Modify Mapping & Geocoding content to incorporate the Mapbox Access Token changes I suggested yesterday at 10:03 am using the info window style suggested by @josh in his follow-up comment at 12:47.
6. Modify Mapping & Geocoding Google Maps API Key to only include this description text: "Enter a key from Google authorizing usage of it Maps services (detailed instructions here)". The limited Google support we provide here may help drive users to our preferred Mapbox provider, which I think we all agree is a good thing.
7. Keep the new About Us and Switch UI sections from Rev 5.
8. Keep the modifications made to Need Help? in Rev 5.

Please vote thumbs up or make suggestions... (edited)

[joshreisner]

Thanks for all the work you're putting in to achieve consensus @kiyote33 -- my overall feedback is let's try to be as economical as possible with language (it demands user time and energy) and functionality (it demands developer time and energy). But it's looking / sounding great 👍

[kiyote33]

Rev #6 - Waiting Review


Mapbox expands to this when NO Access Token is present