Using the wiki for the workshops

[tracykteal]

For the workshops, we often have more information that we want to convey than is needed when the page goes 'live' for registration, information on things like the dataset or extra information that is relevant to only a given workshop. I've been trying a wiki for this type of information and liking both being able to put all the necessary info on one page or for ease of use, not having to worry about HTML or Markdown or committing to github. This is one of the ones I've used

https://github.com/datacarpentry/2015-05-03-NDIC/wiki

Wikis can be cloned like repos, so we could have a template wiki. But would that start to be too much for instructors? Should we just add places for this extra info on the main index page? Other thoughts or ideas?

[gvwilson]

SWC has tried using wikis a couple of times (e.g., to collect information about setup glitches) - the complaint that came back was, "It's yet another place I have to monitor." That was for sharing information among instructors, not during a workshop / with learners, but I worry it would still be competing for attention with the Etherpad, the workshop home page, etc.

[ethanwhite]

I tend to agree with Greg here. It's difficult enough getting folks to find the main workshop page and the etherpad page consistently. I like having all of this on a single page, which is the landing page for the workshop. So,

Should we just add places for this extra info on the main index page?

+1

On the ease of use point, you can get some of the ease of use benefits by editing markdown files through GitHub's browser interface. Click edit, change the text, add a commit message: it's pretty similar to the flow on the wiki.

[karthik]

I think we should just separate everything (registration, workshop page). When someone advertises a workshop, the one page they see should be something like this:

http://register.csvconf.com/

A quick description and basic details (when, where) with the option to obtain a ticket. That's it. On a side note, I really like tito.io and it allows for custom domains, with codes to reserve spots for the hosts etc.

Then we redirect signed up attendees to another page. This can include install instructions, schedule etc. Again, it should be simple and not include too much extraneous information. For example, this makes me cringe: http://smallerthings.org/2015-08-04-asu_sese/

When has anyone ever used Kate as an editor? Even as a developer, I find the information extremely overwhelming and I would likely cancel my attendance ("this is way over my head") or show up without installing anything. It could be re-written for researchers and not sysadmins/developers.

In a recent chat with Tracy, I was suggesting maybe hiring a front end person, graphic designer to give us two html templates. One for welcome instructions, and a second one for lessons.

For e.g. compare this: http://datacarpentry.github.io/lesson-template/ to http://www.daveliepmann.com/tufte-css/

I find the second one far more readable. It doesn't have to be minimalist like Tufte, but some effort into building a nice template would allow us to roll it out everywhere. Some combination of a good layout, design, + free Google fonts could give us a much more friendly, readable page.

Perhaps we could spend some of our grant $ on hiring a designer to give us two templates, then we turn that into liquid/jekyll.

[ethanwhite]

I think the vision @karthik has laid out here is excellent. I'm +100 and like the idea of spending $ on a designer.

[hlapp]

I agree completely.

-hilmar

Sent from away

On Aug 5, 2015, at 6:19 PM, Ethan White notifications@github.com wrote:

I think the vision @karthik has laid out here is excellent. I'm +100 and like the idea of spending $ on a designer.

— Reply to this email directly or view it on GitHub.

[tracykteal]

My not-very-well-articulated point on this issue was more about the separation of content for workshop advertisement and registration from the content for registered attendees, than about the wiki per say, so I also agree. I also agree with the idea of the designer. @karthik says he'll ask around for someone who might be interested, and I might know someone too, so I'll ask. If anyone else has any leads on a contract designer, let us know.

[gvwilson]

We put everything (registration, location, setup, etc.) on one page because people were complaining that information was scattered in too many places. I agree it desperately needs the attention of a professional web designer - we just haven't been able to find one we could afford.

[karthik]

We put everything (registration, location, setup, etc.) on one page because people were complaining that information was scattered in too many places.

Registration is a one time process. So it seems ok to have only location, host, event summary there. On sign up they get redirected to the workshop page (and also get a link in an email). I think that's reasonable.

It also occurred to me that we could make several small changes for big efficiency gains as we scale. For example, the lead instructors email is always on the workshop landing page. Last minute cancellation emails with verbose explanations are not that helpful and take up valuable instructor time. A good ticketing service should allow for automatic unrsvp and also getting the next person on the waitlist notified. I don't know if Eventbrite does this but the service I listed above does.

Perhaps we should have a working call sometime to plan out and mock up the new workshop page and set up?

[gvwilson]

Perhaps we should have a working call sometime to plan out and mock up the new workshop page and set up? +1 - week of Aug 17-21?

[tracykteal]

A working call sounds good. Week of Aug 17th is fine for me, but I know @karthik is traveling.

[karthik]

I might be able to make it. I'll be in Zurich but don't have anything scheduled on the 17th. Here is the mockup I made for the Zurich page: http://datacarpentry.github.io/dc_zurich/

[tracykteal]

This week has clearly passed us by. How about Thursday, Aug 27th at 9am Pacific? I can block off 9am - noon Pacific for the call and some follow up work.

Goals would be to:

• [ ] identify what we would want on an advertisement/announcement site
• [ ] mock up that advertisement site
• [ ] explore if tito.io would be a better registration system than Eventbrite (we also need to make sure the back end payment side is going to be OK for NumFOCUS)
• [ ] identify what we need on a workshop website with information for participants
• [ ] mock up a workshop website (likely not too different than our current standard)
• [ ] potentially create an 'installation' repo and pull all installation information out of individual workshop repos and instead just have links to installation information from the workshop page. Then we would just have one place where we had to keep installation info up to date, and could also include known issues for installation on that page.

Then we can hopefully turn these things over to a designer to make them look nice.

[tracykteal]

I sent a calendar invite to everyone on this issue to see if the proposed time would work, but it would be great to also have anyone else who was interested.

[apawlik]

I agree on wikipedia that it's another channel to keep up to date with and to update. This comes from my own experience as instructor but also as admin (the sources with info are also important for the hosts, and an admin needs often to brief them on these before the lead instructor is secured).

Contact email to lead instructor on landing page. Some email should be there but not instructor, I agreed. Most email sent before the workshop are actually for hosts ("Is this only for department X? Which room is room A? Will there be lunch?"). However, most of the time (again UK admin experience) the lead puts either the host or the admin-uk email. In the latter case it's sometimes because the host doesn't want their personal email to be displayed - we then forward these emails to them internally (not much work really). The functionality that Karthik described is available via Eventbrite (i.e. notify the next person from wait list) but AFAIK it's not easy to retrieve for an registered attendee how to cancel via eventbrite. They usually email the contact email (see above) and we manually cancel/refund them. In fact I am not sure if an attendee can cancel himself. Though maybe there is some Eventbrite API to do that...

As to Karthik's comments. I have some rebuttals. Sorry. First of all, the SWC template may not be ideal but I have an impression that we're forgetting that its current shape is not something which emerged out of the blue but rather a lot of things are a result of iterative improvements which came from community discussions and experience. OK sure, only a subgroup of the community was involved. OK sure, not everyone was happy with the changes. But I think there is no way to satisfy everyone. So before we condemn and cringe at the existing SWC template it's worth to consider why some things are there.

Registration, info about the workshop aim and setup in one page. Greg already raised one point (people complaining about stuff being scattered and I +infinity this). Another thing is from the UK admin experience. The hosts often want to have something "all-in-one" they can circulate to advertise the workshop but also to pitch it to the right audience. And I will +infinity this again. My experience is that advertising without that info and opening registration leads to very polarised audience which is the most difficult thing to handle, in my experience, when teaching. OK, I know, people won't read the workshop website. Well, some won't but some will.

I disagree with Karthik that people first just have registration and then are redirected to the full info site. Karthik says " I would likely cancel my attendance ("this is way over my head") or show up without installing anything." Well, I think this is exactly what happens when you first jump on registration (because there is no info provided) and then* you see the full description and setup.

Also, the comment on text editors is a red herring. It's about the tools we choose not the layout and the structure of the workshop page. I agree, the choice of the tools should be revised but this is a different topic (like "why Git and not SVN?").

I have taught (usually being a lead instructor, and in many cases and admin / co-host) on average one workshop every 6-8 weeks over the past two years. 95% bother to go through the setup we provide and they don't complain it was "too much" on the website. Of course, this may well mean they are too shy to complain. And I agree improvement is needed.

Karthik's page for Zurich, in my opinion, (sorry, Karthik) also includes lots of stuff on the page but there is Table of Contents at the top which helps with navigation. So why not add that to our template (for now...until we have a designer).

Finally, what I (and other instructors) like is the "pluggable" structure of the SWC workshop template. When taking advantage of Jekyll you can include or not some bits; you can alter some bits; add new stuff and so on. Since we have a community of instructors used to this technology I'd be careful just to discard it and introduce new thing. One problem that people consistently report and I know of at least two instructors who decided to stop teaching because of that, is that the infrastructure changes significantly so fast that every 3-4 months when they step in to teach, they have to learn everything from scratch. They don't have time for this and so they decided to stop teaching.

[tracykteal]

Thanks @apawlik for your comments. I think there are some great things about the SWC template, in particular the 'pluggable' components you refer to. I think there are other places where we can explore alternatives.

I have taught at about 8 workshops this year and have actually had the opposite experience with the current workshop template. That inspired my trial of the wiki, and while likely a wiki isn't the right format, I had a really positive experience with that split announcement/workshop materials structure and the structuring of the information for the workshop for participants.

A few points

• This issue is to explore the idea of alternative templates. I think it's worth exploring other ideas, especially since we're at the point of scaling up, and it will make a big difference in how well we scale if we have good and easy-to-use infrastructure in place. I don't think there's any reason not to template out some alternatives. Learn by doing!
• While there is a lot of value in SCF and DC having the same stack, it doesn't necessarily have to be this way. The main difference, and this is something that came up early on, is that DC doesn't teach git, so we don't require or even expect our instructors to know how to work with git. Setting up our infrastructure with this expectation will I think go a long way to working most effectively with instructors and also providing good interfaces for learners.
• I don't think learners will be confused by separate registration and 'during the workshop' pages. It is standard practice to have a registration site that has the overview information (and I agree that information is very important for setting expectations) and then another site that gets emailed out before the workshop. We can always add a link from the registration page too. Learners just want one page to go to get all the logistical information. That doesn't have to be the original registration page.
• On the point of instructors having to manage too many pages, I envision a world where the Workshop Coordinator sets up the announcement/registration page, and lets the instructors handle the workshop website. This solves one of the current challenges that is that the host often wants the registration page set up before either instructors are assigned, or the instructors are not yet thinking about the workshop, given that it's still a couple months off. Also, as was mentioned in this thread, registration is the domain of DC staff or the host, so not something the instructor needs to be involved in. I can go more in to a vision for that workflow in a separate thread, but the idea is that the instructors still will just have to pay attention to one site - the one used during the workshop that contains logistics, installs, surveys and links to materials (some ideas here - https://github.com/datacarpentry/2015-05-29-great-plains/wiki)

It would be great to have multiple perspectives involved in trying some other templates, so it would be great to have whoever was interested be involved!

[gvwilson]

I strongly agree that the look and feel of the workshop and lesson templates needs a professional overhaul, and I'm all in favor of experimenting with things like separate registration and "during the workshop" pages, but we need to remember that:

1. Every difference between our templates and infrastructure is a cost for instructors and admins, who have to learn the differences and keep them in mind.
2. Every time we make a change, it's an extra cost - several experienced instructors pushed back quite hard against making any more "improvements" this year (see http://software-carpentry.org/blog/2015/07/pushing-back.html) because they were tired of having the ground shift under their feet.

Stepping back, one of the biggest mistakes I've made in the last four years is spending time on technical issues (like templates and tools) that I should have spent on content (what's in our lessons and how we actually teach them). I understand why I did this - I know more about tech than I do about ed, so I'm more comfortable tweaking Python scripts than re-thinking lesson objectives - but discussion in our community would be a lot further ahead today if I'd set a better example.

I therefore propose that:

1. We add questions to the pre- and post-workshop questionnaires about the registration process, how findable things were, etc.
2. We agree to a regular release schedule for template changes - experiments can be done whenever, but changes are only deployed (for example) twice a year.

The first will tell us if we're worrying about the right things; the second will (I hope) encourage us and our volunteers to think about the things that add most value.

Thanks, Greg

[hlapp]

I'm don't have a strong opinion on the template and so consider myself mostly on the sideline on this issue. However, @gvwilson's comment raises some good questions, and I think I'm in general agreement with what I think is motivating his caution:

1. There actually is a cost to templating out alternatives, namely that time is taken away from other priorities. This isn't insignificant, and we do have other high priorities, including in particular cleaning up the lesson material. I'd argue that clean and well annotated lesson material has a far greater impact on instructors' ability to teach a workshop, and thus on scaling up, than does the niftiness of the workshop website.
2. Personally, all I've seen so far about the alleged deficiencies of the workshop and registration website is anecdotes and expressions of subjective taste. No data. Do we pride ourselves on data-driven science or not? Why are we spending so much time discussing anecdotes and different tastes rather than on collecting actionable data?