13:02:28 #startmeeting 2013-10-17 Web Team meeting 13:02:29 Meeting started Thu Oct 17 13:02:28 2013 US/Eastern. The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:29 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:02:29 The meeting name has been set to '2013_10_17_web_team_meeting' 13:02:50 #info Agenda is available at http://www.evergreen-ils.org/dokuwiki/doku.php?id=webteam:meetings:agenda:2013-10-17 13:02:57 #topic Introductions 13:03:09 Please introduce yourselves with the #info command. 13:03:25 #info kmlussier is Kathy Lussier, MassLNC 13:03:35 #info graced is Grace Dunbar, Equinox 13:03:53 #info is Kate Butler, Rodgers Memorial 13:04:22 #info bshum is Ben Shum, Bibliomation (quasi-present) 13:04:23 #info RoganH, Rogan Hamby SCLENDS 13:04:39 bshum should be focusing on his conference. :) 13:04:53 bshum needs to bring back Koha swag 13:05:04 swag++ 13:05:31 kmlussier: I am... doing many things at once. 13:05:44 A small group today. Let's see what we can get done with those of us who are here. People can continue introducing themselves as they arrive. 13:05:58 #topic Action Items for Last Meeting 13:06:31 The action items are 1) kmlussier to convert committes page to a WordPress page so that it can be included in the “get involved” section. 2)graced to do mockups for downloads page. 3) RoganH to continue roles discussion via e-mail on the web team list. 13:07:10 #info kmlussier created a WordPress committees page at http://evergreen-ils.org/communicate/committees/ 13:07:40 For the most part, I kept it the same as the wiki page. However, I did change the introductory text and also updated the goals for the web team. 13:08:07 I also added the page to the "Get Involved" menu. 13:09:09 Any suggestions for changes are welcome. :) 13:09:26 graced: Do you want to say anything about your action item? 13:09:31 #info graced sent out mockups of the download page to the web team mailing list 13:09:45 I think the mockup was received well 13:09:51 So the next step is to make it happen 13:10:08 And add more OpenSRF information to the download software page. 13:10:32 And I can work on that. 13:10:51 graced++ 13:11:24 link: http://list.evergreen-ils.org/pipermail/evergreen-web-team/attachments/20131015/db191868/attachment-0001.pdf 13:11:37 kmlussier++ thank you 13:12:34 graced++ 13:12:38 I like it. 13:13:01 It does highlight an issue we have to deal with repeatedly in the web site. 13:13:04 I do too. 13:13:07 graced++ 13:13:08 We have two very different audiences. 13:14:02 I think, where it makes sense, we need to keep separation of the developer and librarian pages. 13:14:10 graced++ 13:14:33 We don't want to overwhelm someone looking to contribute to DIG, and we don't want to bore a developer. ;-) 13:14:43 Or maybe I'm crazy. 13:15:18 I think that makes sense. But in some areas, like the downloads page, it's difficult to separate the content on different pages. 13:15:52 Well, I do assume most librarians are looking for the staff client only - not OpenSRF or the software itself. So we can do a little there. 13:16:03 I don't think it's a terrible thing to duplicate some stuff on different pages to have those audience portals 13:16:33 Mostly, we just need to have clarity. 13:18:01 So how do we make these mock-ups happen? Do you want to work directly on that page graced? 13:18:24 I will work directly on that, yes. 13:19:06 #action graced to update the downloads page to look like her mock-ups. 13:19:24 RoganH: Do you have time to talk about your action item? 13:19:57 a little 13:20:12 unfortunately I haven't had the time to follow up but I've linked the original post in the agenda 13:20:21 and would still like to have a discussion and feedback 13:21:18 Does anyone have feedback at this time? 13:22:16 RoganH: I'd say fromt he attendence here, we might have to start smaller 13:22:29 and build up to that 13:22:35 graced: I agree. And I proposed that some of those roles could probably be combined. 13:22:36 But I like the structure overall 13:22:47 If folks want I could come back next month with a new proposal combining some of the roles. 13:22:52 The structure was good. I wasn't clear on how the wiki played into things really. 13:23:07 The WIKI part is ... nebulous, to me at least. 13:23:22 I agree with graced. I think getting a consistent corp of volunteers is tough because the community is still fairly small. 13:23:23 I put a few things later in the agenda to talk about it. 13:23:49 I've been getting some feedback from Erica who is quickly becoming both wiki wrangler and in general most knowledgeable person about it. 13:24:22 To me the WIKI is the wild west and demands little maintenance though what Erica is doing is crucial. 13:24:40 If we wanted a more structured and manicured WIKI ... that means a lot more involvement from the web team. 13:24:51 My main thought is when does something need to be 'promoted' from the wiki to the site. Or is that even a goal? 13:25:09 That's an excellent question. 13:25:32 Do you mean, when we pull something out of the wild west and put it on display on the front web site, so to speak? 13:25:52 (I'm having images in my head of two headed buffalo on display in a New York museum.) 13:26:09 Yeah, basically. Or find it useful enough to incorporate into the documentation. Or something. 13:26:24 Is the wiki just a collection of random tidbits or a holding place for things we don't have a spot for yet? 13:26:36 a problem for the Wiki has always been it's haphazard index. I always have thought that the website can offer structure that provides some of that indexing back into the wiki where appropriate. 13:27:01 So... why is there wiki structure in the web site and should it be a goal to incorporate it into the web site proper? 13:27:26 We've been incorporating some wiki pages into the web site. But I think there's still a place for some pages that should always be wiki pages. 13:27:34 * dbs pops head in -- use piwik usage data to determine what might need to get surfaced higher? 13:27:51 kclussier: which ones do you see as the ones that should stay wiki? 13:28:01 Part of that depends on the scope of the web site and we've expanded the web site's scope some but I'm not sure it should incorporate everything in the wiki which is pretty much anything Evergreen. 13:28:01 er kmlussier: ^ 13:28:12 Things like the magic spells page should remain a wiki page. 13:28:31 kmlussier: I agree - things with many many contributors and editors should be wiki 13:28:38 I could see that. 13:28:40 And most of the committee pages are wiki pages. It makes it easier for anyone to add minutes and the like. 13:28:43 That makes sense to me 13:28:46 I like Dan's idea as well. 13:28:49 also wiki vs. web site vs. docs :) 13:28:54 dbs++ 13:28:59 dbs++ 13:29:37 So, 1) guideline of many editors/contributors stays wiki, 2) look at stats for what could go to web site because it needs to be found easily 13:29:54 then hash it out case by case if we need to? 13:29:54 Do we still have a lot of wiki documentation? If so, I would like to see that converted into wiki docs. 13:30:16 I mean, official docs. 13:30:56 I don't think we do. 13:31:06 kmlussier: I don't think so but really don't know for sure. 13:32:12 The biggest issue for me as a use case is the lack of a process for deprecating information on the wiki (or my lack of understand of the existing deprecation process if it exists) 13:32:12 Does somebody want to look at those stats and come back to the next meeting on recommendations of content that should be upgraded to official web site content? 13:32:46 StephenGWills: I agree, but I think Erica made a good start. 13:32:47 * dbs poked the wiki, doesn't think that piwik is plugged into it yet 13:33:15 So, we would need to plug it in and build stats from this time forward. 13:33:40 Didn't Erica have a list of content that needed to be updated/deprecated? I thought I saw it, but I'm not seeing it now. 13:33:59 StephenGWills: Erica at ESI has been doing some work trying to flag information that may be old and of concern but it's not being deprecated yet (as I would use the term) 13:34:22 http://wiki.evergreen-ils.org/doku.php?id=scratchpad:pages_that_need_updating_or_revising 13:34:32 RoganH: Thaks! 13:34:50 #link http://wiki.evergreen-ils.org/doku.php?id=scratchpad:pages_that_need_updating_or_revising 13:35:02 This is jumping ahead but I also proposed we put a banner on the page like this: 13:35:07 https://wiki.archlinux.org/index.php/Template:Out_of_date 13:35:13 #link https://wiki.archlinux.org/index.php/Template:Out_of_date 13:35:52 The question I have is who makes the decision that a wiki page from that list should be deprecated. For example, I would recommend getting rid of http://wiki.evergreen-ils.org/doku.php?id=scratchpad:acq_serials 13:36:36 kmlussier: How about archiving for historical purposes instead of getting rid of? 13:36:41 RoganH: I like the banner idea. At the top, though. 13:36:43 With it being a wiki technically anyone can but we're obviously trying to not be cavalier with other people's work. 13:36:47 but yes, it is very out of date 13:36:59 I think the banner is a way of at least warning people. 13:37:22 But I also think we could have another banner that says "if this isn't updated it will be removed", put it on a list for removal after X days and then do so. 13:37:56 or use a voting mechanism. I think I've seen as many mechanisms as n - 2 where n = number of wikis in the world 13:38:26 heh. 13:39:15 I'm in favor of the flagging for eventual removal approach so that if someone is passionate about it they can have a chance to update it. 13:39:31 And if no one cares it can go away. 13:39:39 If we have an archived section, a process that empowers a group, like the web group to mark something as going to archive in…say… a month if no one objects and then it being moved into archive seems like a reasonable approach? 13:39:44 I don't know the best way to handle this, but I would love to see a process where people who are experts in a certain area carefully reviewed the flagged pages. 13:39:57 We can nag. 13:40:15 kmlussier: I would too but that manpower limitation is the ... well, issue. 13:40:28 that way, if someone REALLY has to have an old piece of content, they can go get it and restore it. 13:40:29 dbs: Piwik used to track the wiki. I suspect that we lost it during the transition to wordpress and knocking off the old headers/footers. The wiki itself, I'd like to see some new theming for eventually. 13:40:33 * dbs is in favour of deleting with very little prejudice, rather than letting outdated / incorrect info be found in search engines 13:40:33 I looking at that acq/serials page more closely, I can see there are links that might still be useful. Like the link to sample sets of serials patterns. So those links need to be put elsewhere or the page needs a new purpose. 13:40:47 graced: I think that if we made a list of articles ready for archiving we could also send out that list once a month. 13:40:54 graced: and nag folks :) 13:40:58 I just don't want to lose the history of Evergreen. 13:41:12 I think that would work, Rogan 13:41:25 I wonder if you can bat robots away from a section of a wiki? 13:41:33 you must be able to. 13:41:34 I'm not in favor of archiving either in this case but I will go with majority vote. 13:41:42 StephenGWills: you can prevent access to particular pages, sure 13:41:55 Or if we archived do it in some way that won't confuse things. I don't have any bright ideas there. 13:42:19 archive = copy the filesystem into git on a monthly basis? 13:42:21 I'm amiable to that idea, blocking the deprecated pages, essentially archiving them. 13:42:33 good thing about dokuwiki is that it's purely file-based 13:42:42 I'm in favor of archiving somehow as long as it isn't searchable. Git would work. 13:42:45 heh… delete with prejudice and point objectors to the Internet Archive? :) 13:42:47 dbs: it's just flat ascii right? 13:43:09 saving a copy not in the live wiki seems reasonable 13:43:11 RoganH: flat text files (can include unicode - :) ) and whatever files people have uploaded 13:43:53 OK, so we're looking at the wiki wrangler putting out regular e-mails with a list of pages that either need updating or removing. People have 30 days to review it and, unless the content is updated, we archive it into git? And nagging will be part of this process. 13:43:56 The wiki also tracks history if you go back to see recent changes on any given page. So even if a page is "deleted" if you can find the exact URL and then click through the history, you can see it. (not sure how far back that goes, but it doesn't seem to have limits) 13:44:07 Are we proposing moving the whole wiki, a snapshot of it, to GIT everymonth before removing deprecated content? 13:44:11 I thought the page was gone for good once it was deleted. 13:44:36 RoganH: that was my understanding 13:45:02 graced: OK. Just trying to be clear for the record. I'm very slow after all. :) 13:45:12 hardly 13:45:13 kmlussier: An example of a page I "deleted" a few weeks ago - http://wiki.evergreen-ils.org/doku.php?do=revisions&id=acq%3Aedi_configuration 13:45:27 OK, then change what I said. If people don't update it in 30 days, it gets deleted. 13:45:42 acq:edi_configuration is in the official docs, so I "removed" it. But if you remember the exact page, it's still retrievable via the "old revisions" link 13:45:44 lol 13:46:05 So, I propose that we flag pages with two kinds of banners. 13:46:11 Does the process I outlined above reflect what we've been saying? 13:46:35 1) Needs attention, but not flagged for removal. 2) Inaccurate content that is flagged for removal in 30 days. 13:46:51 +1 13:46:56 +1 13:46:58 We keep separate lists of each type and send out both each month to the lists. 13:47:11 +1 13:47:14 This builds on what Erica has already started. 13:47:17 +1 13:48:01 +1 13:48:18 If there are no more votes I will consider that passed. 13:48:45 #agree Wiki wrangler(s) will flag pages with two kinds of banners: ) Needs attention, but not flagged for removal. 2) Inaccurate content that is flagged for removal in 30 days. The wrangler will send out both lists to the listserv on a monthly. Content with the second type of flag will be removed if it hasn't been updated within 30 days. 13:48:50 I hope I got that right. 13:49:01 Looks good to me. 13:49:14 OK, moving on. We may need to stop the meetig before we get through everythig. 13:49:24 We talked ahead a good bit though. 13:49:40 I'm going to skip the next agenda item and bring the discussion back to the list if we don't get to it today. 13:49:50 #topic Grace asked about doing more mockups versus experimenting with the page. 13:50:16 Is that in regards to the downloads page (which we already discussed) or is it a more general question? 13:50:17 I think that was discussed earlier. 13:50:31 I'm happy to mock things up for review for anything if we want to do that. 13:50:32 She already said she would work directly on it so that's resolved. 13:50:44 Nah, just do it. Rapid prototyping in production. :) 13:50:55 * kmlussier agrees with RoganH 13:51:03 * gmcharlt echoes "agree, agree" 13:51:11 new items 3 & 4 are resolved as well I think 13:51:15 RoganH: Would you say items 3 and 4 on the agenda have been covered then? 13:51:21 OK, then I'll go back to mine. 13:51:22 kmlussier: yes 13:51:34 #topic Potential accessibility issues with “Learn More” buttons 13:52:00 Alexey mentioned this on the web team mailing list, and, after following up with his links ad doing more research, I think he's right. 13:52:42 Don't screen readers pull from the alt-text tag? 13:52:47 Using "Learn More" for those buttons can be ambiguous for users with screen readers who might be listing links on a page. All they will hear is "Learn More," "Learn More" without any context. 13:53:23 graced: They do when there is an image with an alt tag. But these aren't images. They are using CSS styling. 13:53:32 the idea would be to use more specific action verbs? 13:53:41 kmlussier: ah, thanks for the explanation 13:53:47 That text is customizable I believe, but it's shared by every button on that particular landing page. 13:53:59 or at least that's how it works in the default theming 13:54:15 gmcharlt: I think so. There is a title for each of those links that is more specific, but apparently screen readers don't read title by default. 13:54:43 I do think the learn more buttons are appropriate for sighted users, though. 13:54:45 Yeah "button text" is a single shared variable for the theme. 13:55:11 bshum: Yes, I had looked at the them a little too. I didn't see a way to easily address the issue there. 13:55:17 s/them/theme 13:55:45 So, we have to use something else. 13:56:05 Anyway, I don't think it's something we can totally resolve now with just 4 minutes left of meeting time, but maybe it's something we can look at over the next month? 13:56:25 I like the suggestion of using hidden text just for screenreaders, but that won't work if the button text is global. 13:56:32 kmlussier++ 13:56:55 I'll add it as an action item for myself to look at it. Or to bug bshum about it. ;) 13:57:02 Agreed, let's continue to look this month at it to try to find the best solution rather than rush it right now. 13:57:20 Replace it with cats! 13:57:27 #action kmlussier to explore options for the "Learn More" buttons on the Evergreen home page. 13:57:33 Anything else? 13:58:10 #endmeeting