Randall (Randy) Rensch
My feedback
81 results found
-
7 votes
An error occurred while saving the comment An error occurred while saving the comment Randall (Randy) Rensch
commented
By now I grudgingly acknowledge that WA won't be including a wiki in my lifetime. But I will still pray for the other types of end-user help features I mentioned below.
The reason for this post (May 2019) is to update our organization's experience with my latest wiki experiment.
Last summer I set up the Blue Spice variety (free version) of MediaWiki (basically the software Wikipedia uses). It has a WYSIWYG editor built in. This is my third try at getting wiki acceptance. (Two tries aimed at our members generally, one try for use only by our leadership committee.) Like the earlier attempts, this one landed with a thud. Or rather, it, too, never took off.
Three things are needed for a wiki to fly:
1. Management support. In fact, it should be championed by management, one way or another. (By reminders and publicity, or by fiat, depending on the organization's culture.)
2. Easily apparent reason for the wiki's existence, and equally apparent ease of use (no training required to access or enter text).
3. On launch, it should already have substantial content, so that people can begin using it immediately, and learn by example how to find, add and update information.Our latest version has 2 and 3, but except for very brief lip service, none have had #1. If it had, I'm still not sure it would have caught on, at least not without constant reminders, because in each case, even my closest and most earnest friends looked at it once and never returned. Out of sight is out of mind. So, along with management support, it must not be a separate thing -- it should be integrated with the website menu and not require a separate login. (Many of our members don't even know how to do log into the website, but that's our own failing.)
IMO, part of the failure is a larger failure of our leadership to maintain constant contact with our member base, apart from events promotional emails. At one time I even envisioned that "Stick it in the wiki !" might become a catchphrase at meetings. No way.
Depending on the nature of your organization and leadership, maybe a wiki will fly. But given that the concept may be too sophisticated for some non-professional cultures, this all points to the importance of other ways WA could integrate and facilitate the exchange and retention of organizational knowledge.
An error occurred while saving the comment Randall (Randy) Rensch
commented
FWIW, in one of my comments below, I stated, "Wikimedia has now evolved to include a visual editor (beta, but it seems ready) that makes text entry, formatting and image-inclusion a breeze ..."
The "sandbox" demonstration that WikiMedia provides does make it look easy to use. But the many organizations using shared-server hosting might find it virtually impossible to install without expert insight into the instructions and what the process entails. The instructions for installing MediaWiki itself, and the Visual Editor extension, are fairly easy to grasp and execute. But the Visual Editor also requires the installation or use of other software, and to me the instructions seem like so much gibberish. If you want to set up a WYSIWYG wiki on a separate hosting account without having to hire a consultant, I suggest looking around at free options that might be easier to install and administer. That's my next step.
A sample of what you may need to do after installing MediaWiki wiki and extension themselves:
https://www.mediawiki.org/wiki/VisualEditor/Installation_on_a_shared_hostAn error occurred while saving the comment Randall (Randy) Rensch
commented
(Due to length, I've posted this reply as two numbered comments. Please read them in "1, 2" order.)
1.
We're a non-profit volunteer organization, run by about a dozen individuals who volunteer their time for a year or two and then, burnt out, revert to being ordinary members, helping with a chore now and then. Before coming to WA, we had a traditionally hand-cobbled website hosted on a shared server. Our operations were facilitated by a using a custom system that one of our members had written several years earlier, when he was a budding programmer looking for experience and work. By the time I was Webmaster, he no longer had the time or interest in maintaining it. But, for an amateur "spaghetti coder" like me, PHP is a relatively simple language, so I developed the system further. Ultimately, we had a WYSIWYG email editor that sent email (scheduling was flexible although not as extensive as what system WA provides us), stored member and non-member records (including tracking of manually tracked manually entered dues payments and event participation, but not event payments), built and updated our events calendar (I was on the verge of making it fully a CMS), and displayed basic orientation for the people running the club.My successor decided, though, that our club shouldn't depend on one person knowing how it all fits together. Agreed. More immediately, we were using our original PHP version, no longer supported, and our code was crippled by an incompatibility with newer PHP. Our only other option was to hire a consultant at maybe many hundreds of dollars. (Too late, I realized that it was a simple change in date handling syntax.)
Anyway, here we are at WA, and the reason I mention all the above is that although WA gives us some additional functions, bells and whistles, using them has turned out to be as complicated as using our proprietary system. Even to set up an event, it's quite a learning curve. (In fact sometimes harder, because, for example, creating an event description, even from a good template, requires graphic judgment and ability to follow a format, whereas with our Content Management System, just enter the data, and it flows in to the prescribed format.)
During this transition, I tried introducing a wiki, using MediaWiki, the open source program used by Wikipedia. I chose it because at the time other options were unknown vendors whose pedigree and viability was unknown.
The concept, which other members still agree is valid, is that if, when someone does a task, they quickly enter that knowledge into the wiki, someone else can then format it and clean it up, and eventually we'll have a robust operations manual. (Decades of experience have sadly proven that most individual volunteers will not themselves document, maintain or even retain a manual for their successor.)
The wiki would have multiple potential benefits:
* Knowledge would be gathered and maintained, assuring that future generations (and our club is that old) will understand how to keep it going.
* Knowledge can be easily updated. (Everything evolves; our membership, interests, options and time pressures are not the same as they were 30 or even 10 years ago.)
* Being able to see how simple a task is, someone is more likely to accept it. Our club depends on this spirit of collaboration.
* Breaking chores down into their basic tasks also makes each assignment easier, thus enhancing active acceptance of responsibility.
* The people who run the club would have themselves an organized Operations Manual. Furthermore, the volunteers who succeed them (and the committee that cajoles them into volunteering) would know what they're getting into.So, what happened to my experimental wiki? It never got off the ground, but not because the concept isn't valid. I can't answer that, because few people even looked at it. Those that did, did not come back. And I don't blame them. I did not promote it, because the MediaWiki editing process is akin to writing simple HTML -- super scary to most people, and outright clumsy even for me. Uploading and including images was an even more complicated process.
Wikimedia has now evolved to include a visual editor (beta, but it seems ready) that makes text entry, formatting and image-inclusion a breeze, so I'm about to give it another try. Most of our people are equipment geeks, not computer geeks, but they're fine with Google docs and forms and (some people, not me) even spreadsheets. To serve the ends I've described, any wiki will need to be an easy concept to grasp, easy to organize, and producing pages that won't bore today's non-readers needs to be a no-brainer. Unfortunately, installing, maintaining and upgrading a WikiMedia wiki on a shared server brings us back to a need for expert knowledge which we ain't got.
Randall (Randy) Rensch
supported this idea
·
An error occurred while saving the comment Randall (Randy) Rensch
commented
2. (continued from 1)
Given Wild Apricot's organization concept and your touted service of doing away with spreadsheets and the need for specialized knowledge, I think a wiki component -- or the facilitation of user and member education in some way -- should be a fundamental part of WA.
Are there other possible solutions? Yes. Although, they are limited more to admin functions (except maybe for a forum and basic website), WA could incorporate them, as well or instead. Here are some that WA surprisingly has none of:
Admin end-user support (making the traditional distinction between the "user" who creates or customizes the system, and the "end-user" who simply uses it). Give us an easily editable and formattable custom help page for each WA admin screen. It can pop up, whatever. It should be as easy to maintain as an Event Description. You might even think of it as a "distributed wiki"?
Another way of implementing such Help would be to give us a "?" button beside each Admin form field. We would write our own instructions, as to what data to include (and not), how to format it (eg. "Annual Picnic - Springfield, June 22"), where else it goes, whatever.
Give us a space to store our knowledge, even if not really a wiki. For example, we have dozens of reservationists ("Organizers) and need to pass their contact data etc from the person who enlists them to the people who maintain our website and events. But they don't all sign on at the same time, and they get replaced, etc. How must we distribute this data now? Yikes! The dreaded emailed spreadsheets. And in addition to some people being repelled by spreadsheets, we never know if we're working on the latest one. That there is no facility with WA for us to store this list and share and update it collaboratively is almost unconscionable. If there is such a thing, please let me know. (And please don't just refer us to GoogleDocs ... a central, no-brainer solution not requiring special expertise is why we came here, remember?)
While I'm at it, a utility for actually resizing images is another thing that should be integral. We have naive event-creators actually uploading images straight from their camera. Why must we educate them on how to find an image utility on their particular computer (and for privacy and security reasons, preferably NOT some obscure online service)? Integrate it with the editor!
WA is a nice start. But you need to stop adding bells and whistles until you have fully filled out the core functions that many of your customers need.
Any suggestions as to other ways we might meet the goals I've outlined above will, of course, be appreciated.
An error occurred while saving the comment Randall (Randy) Rensch
commented
To begin with, in a wiki, we would store the knowledge that there is a 5000-character limit here. And that, ignoring all standard usability guidlines, you don't disclose it until AFTER I click Post Comment.
So pardon me if I submit my long answer in two parts ... :-)
-
74 votesRandall (Randy) Rensch
supported this idea
·
-
2 votesRandall (Randy) Rensch
shared this idea
·
-
39 votes
Evgeny Zaritovskiy
responded
See also related suggestion – http://forums.wildapricot.com/forums/308932-wishlist/suggestions/8827180
An error occurred while saving the comment Randall (Randy) Rensch
commented
To add to my comment of almost THREE YEARS AGO ...
In addition to having a Reservationist and an Organizer (each specific to that event), we routinely cc registration emails (using a hybrid system involving our domain registrar) to the respective Manager for that type of event, and sometimes one or two others. Unless WA made the list of optional recipients customizable by us, it would be cumbersome to include so many options. It would work just as well to be able to set up each event as a distinct Contact and autoforward from that Contact to the multiple recipients. I've just spoken with Support, who says currently that is not possible. A separate wish.An error occurred while saving the comment Randall (Randy) Rensch
commented
Allow two or more people to be associated with an Event. E.g., there might be co-Organizers, or there (often) might be an Organizer and a different person as Reservationist.
Randall (Randy) Rensch
supported this idea
·
-
1 voteRandall (Randy) Rensch
shared this idea
·
-
10 votesRandall (Randy) Rensch
supported this idea
·
An error occurred while saving the comment Randall (Randy) Rensch
commented
The Event Organizer receives an email for each registrant. That is not the same, nor nearly as convenient, as automatically receiving the full updated list with specified details. I've just had to explain to one of our members (a retired Art Director who organizes a certain event only twice a year) how to import a data file into Excel (etc.) or Word for the simple task of producing a simple sorted attendance list for various uses at the event. That should not be necessary when every one of our Organizers has a similar need.
Also note that an "Organizer" is not necessarily the same person as a "Planner" or "Reservationist," and that none of these people necessarily have admin privileges. (In fact, in our case, only a few of them happen to be admins.) This means an Admin must be troubled to select, export and email data to the Organizer(s) at various stages before the event.
And, various volunteers have different ways of organizing data. Many use a spreadsheet. Being a writer, I prefer a Word table. But our club doesn't care if they use index cards, as long as it works, they're comfortable with it, and it's not a lot of avoidable work.
The option of automatically sending the Organizer an updated list or data file (weekly, daily, when changed, when triggered, etc.) would remove all this hassle and make it easier for us to manage and recruit volunteers.
Regarding the information at "Changing the event organizer" link you mention, it includes advice on how to email to multiple organizers by creating an "email group." That link goes to a Google service (not mentioning that's the target), which requires a Google login account and yet another conceptual and learning process. If we liked the idea of setting up and managing external accounts, more passwords, and using spreadsheets, my predecessor would not have moved us to WA in the first place.
-
86 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
I erred in saying that it is not possible to exclude one's own maintenance and site-checking visits from Google stats. It is possible. Here are two introductions, and you can find more by ... Googling.
I haven't yet tested to see how easily it actually is, nor for suitability with Wild Apricot. But I'm hopeful. I'm also slightly encouraged by some other WA customers recently saying that Google's various free cloud products are easy to use. That has not always been my experience with starting from scratch. I still think overall Google (beyond mere searching) services are easy to use only if you've used it before, knowing the labels, terminology, navigation, etc.
We all tend to forget the frustrations of the learning curve, or may be unaware of them if we had a mentor.
http://www.daniloaz.com/en/5-ways-to-exclude-your-own-visits-from-google-analytics/
http://www.daniloaz.com/en/how-to-exclude-your-own-dynamic-ip-from-google-analytics/Randall (Randy) Rensch
supported this idea
·
An error occurred while saving the comment Randall (Randy) Rensch
commented
Correction: Below, I forgot about sites I managed for several clients. Make that "... for several websites." And to the Wishlist, please add "enable editing our wishes." :-)
An error occurred while saving the comment Randall (Randy) Rensch
commented
I have set up Google Analytics for two websites, one of them my own. I wouldn't wish it on anybody short of a dedicated webmaster. Google is notorious for its poor usability -- like driving in certain East Coast cities, it's impossible to tell where you are unless you've already been there. I've used various state reporting systems, dating back to WebTrends (which I loved).
Also, Google does not provide all the statistics mentioned in the wish. Or if it does, they're not all clearly visible and recognizable, in one place.
But most importantly, Google and virtually all other affordable or free reporting systems do not provide for excluding admin visits. If you're Lands' End or Proctor and Gamble, our own visits are statistically insignificant. But in a small organization's traffic, admin visits (including site editing, testing, and simple visits) grossly skew the stats.
WA provides a Help page on setting up Analytics. If there is any advice on how to make those statistics actually meaningful, I don't recall seeing it.
-
6 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
Correction:
My suggested list included "3/12/10 (shortest US order; the traditional UK order is already an option)"The US order, too, is already on the list. This version just omits leading zeros.
Additional wish: Enable Wishlist contributors to edit their posts, at least for, say, half an hour after posting. (That is the policy of some CMS systems.)
An error occurred while saving the comment Randall (Randy) Rensch
commented
Although I see this has received only 2 votes in a year, it is a significant need (see examples below). I suppose the low vote count is because most WA admins are not familiar with setting the date format, as it's usually done only once, when the account is opened.
To illustrate, the current options are limited to:
12/03/2010
03/12/2010
03.12.2010
03-12-2010
03 Dec 2010
03-Dec-2010
2010-12-03
Friday, December 03, 2010
Fri, December 03, 2010
December 03, 2010
03 December 2010
3 Dec 2010Maybe this list seemed long and varied enough to satisfy a Russian programmer in 2010, and the needs of actual users since then are a forgotten issue?
My main concerns are brevity and including the day of week.
An example of Why this need is critical: Our meetings are usually on Wednesday. Next week's meeting will be on Monday. On our calendar and in our email, our admin naively used only the macro for the date. And of course NOBODY noticed that the date is a Monday.
And in general, it is important, because people can instantly relate to and remember "the event is Thursday" whereas "the event is March 14" they would have to look up.
Suggested additions to this list:
Fri Dec 3, 2010 (short and clear to all nationalities)
Fri Dec 3 2010 (shorter still; my choice for international readers)
3/12/10 (shortest US order; the traditional UK order is already an option)
Fri 3/12/10 (shortest with day of week)
Fri 12/3/10 (for the UK etc.)
Dec 3 2010 (after all, you have 3 Dec 2010)
Dec 3 2010 (Fri) (for good measure, but my preference is to put day first)
All current options but without leading zero(s). (Leading zeros (I've learned by Googling) are a standard mainly in post-Soviet states. Needlessly formal and lengthy elsewhere outside of programming circles.)And one more option, although I'm not sure I would make it sitewide. In ordinary emails and calendar descriptions, it is seldom necessary to include the year. To humans, if I say an event is next Friday, Dec 3, I don't have to say 2010. Maybe there could be an option to omit the year if the date is within, say, the next three months? But that would require significant system programming, testing, etc.
And including ordinal versions (Dec 3rd, 2010) and clarification of 12 pm as being midnight or noon would be a step too far.
But adding these other clearer, shorter options seems a no-brainer.
An error occurred while saving the comment Randall (Randy) Rensch
commented
It's good that you provide many alternatives for default date formatting, but you left out one of the most valuable: Full information in shortest form, namely:
Fri Dec 3, 2010
Would you please add it? Also note that I have omitted the leading zero. Including the day is very helpful to making the date memorable ("Oh, next Friday"), but "Fri, December 03, 2010" is attractive only to a computer.
I would even go so far as suggest that 99% of the time, we don't need to show the year, either, but I don't know how you would make that optional in a default, and I haven't surveyed all our situations where it occurs.
Randall (Randy) Rensch
supported this idea
·
-
4 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
Evgeny -- Not exactly a propos of your comment, but I hope of some interest:
We do not accept non-members to attend at our lodge unless there is a Member present (for obvious reason). But unless we manually intervene in the display of non-Member registration, we sometimes wind up with non-Member registrations and no Member. (Only once in hour history have we wound up with ONLY non-Members signed up, but it does meanwhile make for some embarrassing explanations. We all agree that if someone Registers, they should consider that effective, not cancellable by us if no Member attending.)
What we'd like is for non-Members be able to put themselves on the waiting list until a Member registers, and when a Member does, the waiting list is automatically converted to registrations. (We would also want a confirming email to be sent to those who were waiting.) And the non-Member form(s) would then be open to whatever number of Registrants we set.
Currently to do this, we'd have to set the non-Member form max to 1 attendee (the system interprets 0 as unlimited), create a dummy non-member registration to activate the Waiting List option, then readjust it all when a Member registers. Automatic, it would be great. Manually, it's more trouble than it's worth.An error occurred while saving the comment Randall (Randy) Rensch
commented
You're right that not everyone wants to display how many spaces are left. Although we have disagreement even within our own leadership committee, the thinking of the marketers among us is, when a certain number of people need to sign up before it becomes more than a "cozy little evening," why make the event look unpopular and have people shy away? "Spaces left" can even be misinterpreted by some prospective attendees, not realizing that some people typically wait for the deadline before committing ... meanwhile the event looks unpopular. Of more concern to me (and possibly much more commonly), it encourages people to game our system, as our prices and procedures differ when there are only a handful of people.
Displaying "spaces left" makes sense to me only as the event begins to fill up. Yes, when only 7 spaces are left of a 40-person limit, then it becomes an encouragement to act now -- just the opposite of its effect at the beginning.
-
1 vote
An error occurred while saving the comment Randall (Randy) Rensch
commented
Hmm. The Wishlist system here seems to be changing a " to the HTML entity for it ("). Be sure to use the quotation mark instead. Single quotes might suffice.
An error occurred while saving the comment Randall (Randy) Rensch
commented
Apologies for a typo in the #1 code below. Should be:
<meta http-equiv="refresh" content="0;url=https://www.yourdomain.org/Sys/Login" />
BUT SEE THE WARNING IN MY INSTRUCTION BEFORE YOU USE IT.
And if moving to Trash, be sure you use the rightclick flyout next to the page in the list of pages. If you use the Move to Trash link button at the top of the dashboard, I fear you might instead delete the page the system redirected to, which could be your home page or whatever a 404 defaults to.
An error occurred while saving the comment Randall (Randy) Rensch
commented
I assume your reason for wanting this is that the login link is sometimes not noticed in the corner of the page? There may be better solutions for that, but here goes...
#1 is the cleaner for users, as it is more direct. However I would not use approach #1 without touching base with Support first. At least do it only during hours that you are sure of being able to reach support. I'll explain below.
1. Create a new page as usual. Create a Custom HTML gadget space on it. (A Custom Content gadget is optional.) Click the Edit Code button (at left) and insert a standard Refresh meta tag. (Putting it in the body is unorthodox, and is not optimum for SEO, but it will work.)
<meta http-equiv="refresh" content="0;url=https://www.yourdomain.org/Sys/Login/" />Put the page on your menu and when the user clicks it, they will
immediately be taken to the login page.
HOWEVER (IMPORTANT!)...
If you need to edit the page (e.g., error, change/add content), the page will redirect in the WA Site Pages editor (probably to your home page),
making editing it IMPOSSIBLE. It will redirect even if you have included a delay to give you time to click Edit! (Which would also delay it for users, so that's not a good idea.) If you must use this method for some reason, first save a version of the page without the meta tag (or comment it out), and then save the "final" version of the redirection page. Then if you need to edit it, rightclick to choose the earlier version (without the redirect), make your edits, including the meta tag with zero delay, and resave. If you've wound up with two redirect versions live (I haven''t tested that far), rightclick to delete the unwanted one. Whew!2. This approach is simpler, kosher, and barely more trouble for your members. They won't think it odd: Create a page with the login link and save it on your menu. Done. A user clicking on the menu will get your page, and when they click the link, it will go to the login form.
<a href="https://www.yourdomain.org/Sys/Login">LOGIN</br></a>
As always, have several people test, who are unfamiliar with what you are testing.
However, if you think (as I do) that regular communication with Members helps make them feel wanted, this may be a good excuse for a few lines in your newsletter or "letter from the President." Telling them how to login might be helpful. A lot of our members still think everyone has the same password which they have to remember.
-
1 vote
An error occurred while saving the comment Randall (Randy) Rensch
commented
Hopefully you've found the answer by now, but here goes ...
In the HTML window, edit the link to include a "target" tag. Typical advice is to add _blank, as in <a href=http://whatever.com" target="_blank"> . The target page will open in a new window or tab, depending on the user's browser and configuation. But if you have a lot of external links, that will clutter the user's screen with a new window or tab for each link. Depending on the situation, that could be desirable, or could be annoying. If you want each link to open in the same new tab or window, give it a name (as in <a href="http://whatever.com" target="Chtywin2") and use the same name in each link.
I usually add something distinctive to the name (as you see) so that the browser won't confuse it with a window opened by another site that they happened to give the same name (however unlikely that is).
But you can call the window any darn thing you want. If each has unique name, it will open in a new window, so from one web page you can send some links to one window and other links to one or more others windows
Remember that the user might not realize that a new tab or page has opened, especially if they on a smartphone (where the new page might be under the one they're viewing), so if space and situation permits, consider mentioning "... will open in a new tab or window."
The same technique can be useful for internal links. For example, here's a page at my site (non-WA) that shows the user a photo. I don't want them to inadvertently close the photo and leave my site. I do the same thing when linking to a PDF; I'm constantly accidentally leaving sites because I forget I'm in a browser, not a PDF reader.
-
5 votesRandall (Randy) Rensch
shared this idea
·
-
6 votesRandall (Randy) Rensch
shared this idea
·
-
44 votesRandall (Randy) Rensch
supported this idea
·
-
199 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
I've already commented that this wish, maybe combined with the addition of a second Organizer (assistant, reservationist, whatever) would be firmly in the Top 5 of our organization's wishes, so I won't go on about how we would use it.
Meanwhile, for those here who mention that the Organizer of a single event should not receive emails regarding other events, note Support's advice that each event can have a separate organizer. But that still leaves a problem: Unless the Organizer is herself registered, she will receive all the promotional emails for it.
We have a privacy workaround that involves setting up an autoforward "event address" for each event, at our hosting service. After entering that event address in our Contacts list, it is then specified as the Event organizer. It's a Rube Goldberg scheme, and requires setup by someone trusted to access our hosting account (2-5 min chore for each address) but it works. We can forward simultaneously to the various managers in involved in the event (somewhat obviating the need for separate Manager, Organizer and Reservationist fields), and the Organizer's personal address is not broadcast to our entire mailing list. (However, unless a special Gmail (etc) account is used, it will be disclosed to Registrants who the Organizer contacts. The relevance to this thread (sorry for burying the lead!) is that unless the event address is configured to opt out of mass mailings, the Organizer will get all the promotional emails about ALL our events. Luckily that setup is very easy and a one-time thing.
Alternatively, if privacy is the only concern, maybe each Organizers could have their own Gmail address. I don't know offhand if Gmail can be configured to autoforward. If so, that would resemble our system. But without autoforwarding, accessing a special Gmail account would be yet more work for the Organizers and those who teach them. And it would be a ton of work for the Organization to create and configure many scores of Gmail accounts.
Maybe WA should think about ways to pull all these concerns and workarounds together within the WA system. If not, hopefully some of what I've described will be helpful to some here.
An error occurred while saving the comment Randall (Randy) Rensch
commented
I'd include this among our top five most important wishes. We run scores of events per year, many of them involving registrations, which are managed by a Reservationist. They are volunteers. Some handle one event, some handle recurring events. Many of them are ordinary Members who should not have access to Admin functions and data, but they do need access to data for their particular event.
Giving them that access would make it SO much easier for them to do their jobs, and thus to recruit volunteers, and simplify life for the webmaster and other admins who manage them.
An error occurred while saving the comment Randall (Randy) Rensch
commented
Give Organizers admin access (only) to their own event. It's absurd that our Organizer/Reservationist for each event has to depend on an admin to email them a spreadsheet just so they can track who has signed up and status etc. But we do NOT want to give these dozens of Organizers full admin privileges. Also, their access should expire when the event has passed, or a specified period thereafter.
Randall (Randy) Rensch
supported this idea
·
An error occurred while saving the comment Randall (Randy) Rensch
commented
PS: Thank you for your interest, in asking for details.
An error occurred while saving the comment Randall (Randy) Rensch
commented
We are a ski club, and run events of various types. Some are evening get-togethers involving no charge by us (eg. a happy hour, dinner or ice skating at a local venue) some involve a charge (e.g. a party or group-tickets film), some are weekend stays at our lodge in New England. Of those stays, some are bus trips requiring payment in advance, others are carpools where people pay at the end of the weekend.
Each event has a "reservationist" who takes reservations, keeps track of "sales," arranged drivers and riders, assigns rooms or whatever the event entails. For decades we've done this using spreadsheets and/or our own proprietary software (a PHP-written CMS backend that produced our website calendar, created emails, managed data, stored documents securely (.htaccess level) and stored how-to screens). Understandably, we didn't want to be dependent on one or two members who created that system, which is why we turned to WA, which had meanwhile grown more robust and versatile.
Unfortunately, not quite versatile enough for us to use without requiring way more training and managerial effort than should be necessary. Previously, an event would be put on the calendar and various people would make it happen. But now, especially now that this year we decided to try requiring Registration for almost all events of all types, our Reservationists can't even reliably get the registrant data! They get an email, but what if it goes missing? And having gotten all the registrant emails, then they have to, what, create a spreadsheet or some such document? That's missing the point of this system, eh?
So now someone on our management committee (i.e., and Admin) has to export the data, ideally every day, to each and every Reservationist! Multiply that, during our peak season, to two or three local events every couple of weeks, and four weekends a month, and it just gets silly to even consider.
It would work so much better if each reservationist could access the Registrant data for their respective event, ideally with the ability to add or revise data and add or remove registrations, without giving them access to the whole system (with the obvious data and privacy risks in that). When the particular event is over, we would then want to cancel that Reservationists' access either manually or automatically.
By the way, we've always called them Reservationists, but that's also an important distinction. The person who organizes and event is not necessarily the person tracking reservations. Sometimes yes, sometimes no. And sometimes there is more than one organizer. Yet we're limited to one Organizer per event, with our automatic emails going out with their personal address as reply-to. That's both a privacy and a security issue (about which I've placed another wish on the wishlist already), so for each event we create an autoforward at our domain registrar, which is the one we publish and (after putting into our Contacts list and setting preferences so it won't get all our emails), is the one we specify as Organizer.
I hope that gives you a sense of our workflow. I'm not sure my offhand description is as organized as our procedures themselves are, but they've worked for decades, and now with WA, some of our people have gotten pretty confused. Some of it is just the transition from paper to computer, but some is a result of having to shoehorn our systems into your capabilities, which are great in some ways, but in others very limited or inflexible. (For example, the Registration form itself, which I've also already mentioned on the Wishlist).
I'd be happy to walk you through some actual events if that would help. But the bottom line is: help us distribute the workload so that our individuals who volunteer their time to help with an event can truly collaborate and each do a part of the job, without requiring more than supervisory involvement by our management committee members and webmaster, who are also volunteers.
An error occurred while saving the comment Randall (Randy) Rensch
commented
I think this might be part of this wish:
We have several people in charge of various types of events. Each event has a Reservationist (who you call Organizer), who tracks registrations, and payments, arranges car pools, orders refreshments, etc. Currently all a Reservationist receives to work with is a bunch of emails, which in some email environments are hard to organize, hard to work with, and easy to miss (and in one case was questioned as a test or spam). If they want a list or spreadsheet, someone with Admin privileges must download data as a spreadsheet, ideally doing this every day and for every event -- a huge task that should not be necessary and will not be done. (Someone has asked me, if I still have to circulate spreadsheets, why do we need WA?)
We need to give limited or read-only access to each Organizer, so they can see current registration data for their event. Ideally they should also be able to make notes and changes, but only in their own event, and (ideally) only in event-related fields, and they should not see sensitive data.
I would settle for the Organizer being able simply to download the Registrations data themselves, as either a spreadsheet or organized list (text and/or Word file), for their event only, without needing further Admin privileges.
I agree, this is critical. We can't very well give a dozens of Organizers broad Admin privileges. This year we decided to require Registration for all our events (as opposed to also accepting reservations by email), but what's the point if our Reservationists can't access it?
An error occurred while saving the comment Randall (Randy) Rensch
commented
Limited or read-only access by Organizer to registration data for their event.
Currently our Events Manager has to produce a spread sheet every day and email it to the respective Reservationist (Organizer), doing this for EVERY event. An impossible task. And if we need to circulate spreadsheets, why do we need WA? (Sorry)
-
18 votesRandall (Randy) Rensch
supported this idea
·
-
2 votesRandall (Randy) Rensch
shared this idea
·
-
98 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
Although I don't see my comment that was reportedly rolled into this thread, I do have a thought, possibly more important now that this Wish is comparatively ancient:
Clicks can be counted, but an email reported as "not opened" may indeed have been fully read. The open rate just measures how many emails displayed an image (I presume a web bug placed in the email by WA). Now that everybody's checking their mail on phones, your open rate might be much lower than the actual level of interest. My iPhone, for example, doesn't display images unless I tell it to do so on that particular email. In contrast, on my computer, Outlook is configured to automatically display images from senders I have designated as "safe."
In fact, affecting data at the other extreme, if I just scroll through my inbox, the email will be displayed in preview merely by clicking through the list. I may never click to “open” it, let alone read it. (I have not tested to see if Outlook downloads safe senders’ images before previewing, but I doubt it.)I know of no solution to this situation, except to format your email so that the absence of a un-downloaded image is apparent (borders? captions? Alt values?), and to remind that an open rate should always be taken as a **relative,** comparing it with that of other emails and over time.
Although I've read no data on this, I suspect that over time open rates in general have been skewing low.
Randall (Randy) Rensch
supported this idea
·
-
62 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
We've been putting off Archiving hundreds of non-Member contacts who have opted out of both email types, or not attended an event in many years, or both.
We can generate that list. Now, how do we archive them all?
Apparently I have to export to spreadsheet, change the archive flag and re-import? Talk about make-work! Not to mention opportunity for grievous error. (Okay, I've mentioned it.) And some people, believe it or not, are not handy with spreadsheets. (I've pretty much forgotten what little I knew.) In fact, some people shudder at seeing one. I don't blame them. If you don't use Excel regularly, even a simple chore like this is scary and involves a hugely disproportionate learning curve (plus the program).I'm not quite so cynical as to think WA is makes this a chore just to get us up to the next billing tier, but I can't imagine any other reason why this was not a top-ten capability on WA's Advanced Search specification document when you built it.
Randall (Randy) Rensch
supported this idea
·
-
104 votesEvgeny Zaritovskiy
responded
We’re looking into this request in much broader context – we want to simplify overall management of contacts, lists, saved searches. Saved search should be perceived as smart lists and provide quick access to various contact and member groups.
An error occurred while saving the comment Randall (Randy) Rensch
commented
I'm very disappointed to find that Project Manager's latest report on this Wish was in 2015. My own laundry list of wanted Advanced Search capabilities is going on two years itself. I've seen no improvement since then, and there has not been a month where I could have used some.
Case in point: Currently I need to delete hundreds of inactive Contacts from our mailing list (we're nearing our plan limit), and apparently to do so, I have to mess with spreadsheet export/import or do each record manually?
Sigh ...
An error occurred while saving the comment Randall (Randy) Rensch
commented
Make Advanced Search easier to use, test and save:
* Rename saved search
* Longer saved search name
* Report of parameters for all searches (to have a backup record of all our searches before cleaning house, I've had to take screenshot of each)
* Let us disable criteria, for comparing results (Currently must Remove then reconstruct).
* Display full name of Saved Search on tab page (currentlyu appears only in dropdown list, cut off)
* Include field for a description of saved search, and have that description appear as a help note when hovering over search in selection list (e.g, when selecting from list to schedule a send).
* Don't allow user to save search as duplicate name
* Sort saved search list
* Make clear to user the effect of selecting a saved search in Automatic Announcement emails, vs. same search in Manual email. One filters further (those who have opted out of automatic announcements), the other doesn't. Yet, neither we nor our recipients know exactly who is opting out for what why. (If that's confusing, guess why!) When sending a manual email that resembles an automatic one, should I filter out the people that the automatic announcement filters automatically?An error occurred while saving the comment Randall (Randy) Rensch
commented
Make Advanced Search easier to use, test and save:
Rename saved search
Longer saved search name
Report of parameters for all searches (to have a backup record of all our searches before cleaning house, I've had to take screenshot of each)
Let us disable criteria, for teting. (Currently must Remove then reconstruct).
Display full name of Saved Search on tab page (currentlyu appears only in dropdown list, cut off)
Include field for a description of saved search, and have that description appear as a help note when hovering over search in selection list (e.g, when selecting from list to schedule a send).
Don't allow user to save search as duplicate name
Sort saved search listAn error occurred while saving the comment Randall (Randy) Rensch
commented
Longer Advanced Search names, or detailed description of each Advanced Search (e.g., a pop-up) when viewing Searches in list. And while your at it, let us rename Advanced Searches.
Randall (Randy) Rensch
supported this idea
·
An error occurred while saving the comment Randall (Randy) Rensch
commented
Need to be able to rename a saved Advanced Search. Lacking that ability, I saved the tweaked search to the same name, figuring WA would ask me if I wanted to overwrite it and I would say "yes." WA did nothing of the sort -- it just saved the tweaked search as a new search having a duplicate name -- so now I have two identically named searches, one erroneously finding 700+ members of various kinds, the other more accurately finding 225 members of any status and type. I will delete the former, but shouldn't have to.
Not a wish, but a (perhaps vain) suggestion in response to comment by Anonymous on October 25, 2018:
Prior to our using WA, our website's member pages required all members to use the same password. Of the few who attempted to log in, many didn't remember it. I'm pleased that with WA, each member has their own PW and can have it mailed to them.
That also applies to wiki access. If your wiki (or any other outside service) requires a common password to access, consider posting it on a Members-only page on your website. There are even some simple scripts that, on clicking through to the wiki, will put the PW into the user's memory for easy pasting. (For some devices where that code doesn't work, user will have to copy/paste the PW manually, but depending on their browser settings, it might be populated automatically on later visits.)
Since this protection approach is only as strong as each member's choice of password, I would not use it for access to critical data such as a bank account.