Suspended Meetings - Detail View

[Grateful-Viv]

This may go away as you are working through this, but going to report it anyway just in case.

On the meeting detail page for a TC type, the plugin displays in red Location Temporarily Closed. (And yes, it should say meeting suspended or something along those lines, because a lot of these locations have opened up even though the meeting may have not resumed).

So can the TSML-UI display something on the detail page that says in red Meeting Suspended?

See screenshots.

[joshreisner]

It's not currently on the roadmap to add this as the default UI, but you should be able to achieve this with the following CSS:

#tsml-ui .meeting.inactive h1::after {
  color: #d40047;
  content: ' / Meeting Suspended';
  font-size: 70%;
  font-weight: 600;
}

[Grateful-Viv]

Something changed because now /Meeting Suspended is on the next line and looks odd. Originally it was how your image looked above. Now it looks like the screenshot below.

[joshreisner]

this should be fixed now

[Grateful-Viv]

It’s still the same for me.

Also still not seeing image in place of map for online meetings. Or the image I used for inactive meetings.

Is the environment I’m using a development one and subject to changes on the fly? I’m asking because without making any changes on my end (other than re-importing the CSV file), I see things you’re adding or fixing from time to time. For example, the image for online meetings suddenly stopped appearing. Or you added the arrow to explain closed meetings (which was a nice solution).

I’m really leaning towards using this UI as the front end on our intergroup site, but would like to be assured of some stability. Normally I don’t roll out changes on a live site until it’s been tested and even still can roll back if something goes awry.

And would if be possible to add here some of the things I see on the SF/Marin site which are

• Women or Men after meeting name on list view if it’s a women’s or men’s meeting
• Labeling Location to Location/Group
• Labeling Address to Address/Platform

[joshreisner]

Hmm, now that you're on the TSML beta, your site is using the JSDelivr CDN, so it'll be about a 24 hour lag for you to see those changes. The Men / Women flags will also be fixed then. Both issues are fixed on react.meetingguide.org, which updates immediately. (The Men / Women suffixes were dropping below the "back to meetings" link the same way that your custom flag was.)

The system of updating the plugin leaves a lot to be desired. Also that it's only one person working on it in their spare time. We've talked about versioning releases of TSML-UI, but my concern is that then updates will be tied to WordPress plugin releases. We'll talk some more internally about the release process though, we do need to figure something out.

The custom images for online and inactive meetings are definitely something that happened on your site, I can still recreate it by that code to a custom stylesheet. Screenshot below. I'd double check where you added that custom CSS originally and see if something got messed up.

I only have bandwidth to support issues that are a part of the core experience that affects all sites though, not customizations.

The problem with the column names is another attempt to customize, you're inheriting those names now from the plugin. It's something we're discussing internally, but my hope is that we will start finding ways to reduce code complexity by discouraging customization. Each one is a possible point of failure that we spend energy fixing.

[Grateful-Viv]

The system of updating the plugin leaves a lot to be desired. Also that it's only one person working on it in their spare time

As more and more AA entities are using the plugin, particularly during the course of the pandemic, they've come to depend on it and this affects people's lives - particularly newcomers looking for meetings. Perhaps this plugin could include a premium version and use the funds to hire someone rather than depend on volunteers working in their free time.

We've talked about versioning releases of TSML-UI, but my concern is that then updates will be tied to WordPress plugin releases.

Whether it's tied to it or not, I believe there should be a stable tested version and if someone wants to implement the latest and greatest beta version, they should have capability to roll back to previous versions. I know at some point the plugin front end will no longer be worked on. How then can we assure the new releases will work for everyone?

And if you don't tie it to WordPress (at least the Imports & Settings portion), then how will people update their data if using WordPress in a simple, not-to-hard way?

The custom images for online and inactive meetings are definitely something that happened on your site, I can still recreate it by that code to a custom stylesheet. Screenshot below. I'd double check where you added that custom CSS originally and see if something got messed up.

I went back to the CSS and removed some other lines not having to do with with the map image. The offender which I don't know why it caused problems was

div#tsml tr.notes a:after { content: "*"; }  /*-displays asterisk after meeting name to indicate there are notes */
div#tsml tr.location_notes a:after { content: "*"; } /*-displays asterisk after meeting name to indicate there are location notes */

And you said you don't want to use this anymore.

But I still cannot get the inactive image to appear which I am sure is something stupid on my end. It's not that important, so will do without it.

The problem with the column names is another attempt to customize, you're inheriting those names now from the plugin.

But the column names don't fit with the data, especially the location name.

I only have bandwidth to support issues that are a part of the core experience that affects all sites though, not customizations.

My frustration is there are pieces in the TMSL plugins (both the current and beta), and the TSML-UI, that work well and look great. If only they could all be incorporated into one. But I get it @joshreisner. You've been doing tireless work on your own time and many of us owe you a debt of gratitude.

[tech2serve]

This is becoming a bit of a philosophical discussion thread, but I think it is important to expand on some expectations that have been expressed. :-)

Whether it's tied to it or not, I believe there should be a stable tested version and if someone wants to implement the latest and greatest beta version, they should have capability to roll back to previous versions. I know at some point the plugin front end will no longer be worked on. How then can we assure the new releases will work for everyone?

Having releases "work for everyone" is not a goal of our efforts. First, we want tools that function well without major bugs or loss of data. We strive to make a UX that is intuitive while still performing validation of key data fields. And third, it is an imperative that we remain compliant with the specification used by Meeting Guide. I am convinced the vast majority of AA meetings are found through that app, especially when compared to a web-based meeting finder app.

The front end UI is important, don't get me wrong. But a lot of what is being discussed here and in related threads are personal preferences (that said, we are trying to get a UX process initiated). The beauty of CSS is that websites can and should feel free to make their own customizations, but we also need people to understand Code for Recovery must limit the time we spend on these or we fall behind on maintenance of the core features.

TSMLui is a capability in development today. It is great that people like you are experimenting with it, and giving feedback to us. But it should not be considered stable at this time; it will continue to evolve at least for a while longer.

And if you don't tie it to WordPress (at least the Imports & Settings portion), then how will people update their data if using WordPress in a simple, not-to-hard way?

This! Largely due to Josh's work, TSMLui is going to provide groups the opportunity to provide meeting lists without relying on WordPress. One example is a simple spreadsheet. A significant number of people (too many if you ask me) simply keep reimporting a spreadsheet they use to maintain their meeting lists just so they can get the meetings shown on a website and then into Meeting Guide.

We will continue to strive for simplicity while working to provide core products that satisfy a majority (but not all...just not possible) of users' requests.

[Grateful-Viv]

Having releases "work for everyone" is not a goal of our efforts. First, we want tools that function well without major bugs or loss of data. We strive to make a UX that is intuitive while still performing validation of key data fields. And third, it is an imperative that we remain compliant with the specification used by Meeting Guide. I am convinced the vast majority of AA meetings are found through that app, especially when compared to a web-based meeting finder app.

The front end UI is important, don't get me wrong. But a lot of what is being discussed here and in related threads are personal preferences (that said, we are trying to get a UX process initiated). The beauty of CSS is that websites can and should feel free to make their own customizations, but we also need people to understand Code for Recovery must limit the time we spend on these or we fall behind on maintenance of the core features.

The plugin beta version added some much needed functionality such as being able to separate active from inactive meetings, and easily find online v in-person meetings. But there were other cosmetic changes done which didn't add anything to the functionality, but in my opinion, made things less attractive. Please don't get me wrong. I do appreciate the time you've all freely given to develop and then redevelop these invaluable tools. And as far as I can tell with testing the beta plugin and the beta TSML UI, from a functional standpoint, it seems very stable and free of bugs. Massive props for doing all of this. Thank you.

TSMLui is going to provide groups the opportunity to provide meeting lists without relying on WordPress. One example is a simple spreadsheet. A significant number of people (too many if you ask me) simply keep reimporting a spreadsheet they use to maintain their meeting lists just so they can get the meetings shown on a website and then into Meeting Guide.

Perhaps it would be helpful to take a poll here or someplace like the TIAA Forum to see if people would prefer to maintain their data in a spreadsheet. While it may make sense for mass updates (like making a global change using search and replace), a flat file spreadsheet is a cumbersome and time-consuming approach in the long run. At least that's my opinion. And I may be in the minority, so maybe it's time to step aside and let others chime in.

[FlipperPA]

Perhaps it would be helpful to take a poll here or someplace like the TIAA Forum to see if people would prefer to maintain their data in a spreadsheet. While it may make sense for mass updates (like making a global change using search and replace), a flat file spreadsheet is a cumbersome and time-consuming approach in the long run. At least that's my opinion. And I may be in the minority, so maybe it's time to step aside and let others chime in.

Part of the problem with polling in those areas is self-selection bias. The communities there are naturally more technical and educated in the ecosystem of what technologies are available. Often the results become a self-fulfilling prophecy, because the most devoted users are being polled. This is seen through Internet communities. For example, when we gather opinions from the Django Developers mailing list, that's less than 0.01% of the overall Django community, and the most devoted. I haven't come up with a good answer to this problem. :)

As more and more AA entities are using the plugin, particularly during the course of the pandemic, they've come to depend on it and this affects people's lives - particularly newcomers looking for meetings. Perhaps this plugin could include a premium version and use the funds to hire someone rather than depend on volunteers working in their free time.

I would warn against trying to solve technical problems with money. I've had mixed results in my life trying to solve problems with consultants. In most cases, I have had a problem... then I've hired a consultant. Now, I have two problems. Who's going to manage to consultant? Bring them up to speed? How long are they going to be engaged for? Will they be up to speed by the time money runs out, and where does that tipping point occur?

I can understand your frustration, as we are all members of a one-day at a time program. Sometimes it is hard to see progress through that lens. However, when I look at where TSML-UI is now versus a year ago, or two years ago, it is truly a great accomplishment. As you mentioned, much of that progress was accomplished during the strain and stress of the pandemic, which makes it all the more impressive. Kudos to @joshreisner for that!

I just wanted to share my two cents on those issues, but don't want to diminish the value of your feedback, @Grateful-Viv: thanks for providing it. We're definitely trudging the road to happy technology here!

[Grateful-Viv]

This particular issue is fixed now. Thank you @joshreisner

TSMLui is a capability in development today. It is great that people like you are experimenting with it, and giving feedback to us. But it should not be considered stable at this time; it will continue to evolve at least for a while longer.

I prefer this front end to the WordPress plugin. I think we can solve the problem of having "Request a change to this listing" by just using a form that I'd develop on our end for folks to request changes to their meetings. I'd like to start using it, but my concern is if it's still in development that changes will continue to occur on the live site that may break things.

[joshreisner]

We're just starting to sketch out a system, but I think the solution is in this TSML ticket: the TSML settings page should allow you to pick TSML-UI as your frontend (no react shortcode) and if you do, the default would be to use the latest version, but it would allow you to pick (and stay on) a particular version of TMSL-UI.