Shawn: Today we will focus completely on Tips and hoping to wrap those up. Overall, we want to see if we can still publish this week or if they require more polish before first publication. In this case, we will continue to have time and resources to refine and update tips going forward so the final polish can be continuous.

General point on Tips

Shawn: One option then is to publish and continue to work on them. Today we want people to look at recent changes during the call, so if they are OK we can approve them and then look at specific points. Right now we will give you a chance to look at Tips changes and record your response.

<shawn> [reading break while we read through the Tips Changes (that were just listed yesterday)]

<Howard> great work Kevin!

<James> +1

<George> +!

<George> 1

<George> +1

Sharron:What does the "i" icon mean?

<Zakim> shawn, you wanted to say a comment about https://github.com/w3c/wai-quick-start/issues/263

<Howard> have same question about "i" icon

<Brent> My assumption was "i" stands for "information"

<Lydia_Harkey> Had same assumption as Brent

<Vicki> Me too - same as Brent, i for "information"

<George> Same as Brent

<shawn> [Shawn is done reading all]

<George> [George is done reading all]

<Brent> [Brent is done reading all]

<Lydia_Harkey> done

<Sharron> [Sharron is done reading all]

<Vicki> done

<James> [James is done reading all]

<davidberman> David done

<Vicki> +1

<George> +1

RESOLUTION: Accept all recorded changes with the exception of the "i" icon which is to be discussed.

<shawn> +1

<George> +1

<James> +1

<davidberman> +1

<kevin> +1

<Brent> +1

Howard: I thought the previous title, the original was clearer. The new one is more awkward.

<Howard> anyone else bothered by change of title: https://github.com/w3c/wai-quick-start/commit/6fff5de

Shawn: QuickStart Tips is what we called it at the beginning but as we worked with them we have been calling them Tips for Getting Started. This was meant to reflect the reality of what we have been calling them.

Howard:I am OK with the change, but preference was for the previous title.

<shawn> example of (i) s http://w3c.github.io/wai-quick-start/designing.html#ensure-that-interactive-elements-are-easy-to-identify

<shawn> developing rendered & code: http://w3c.github.io/wai-quick-start/developing.html#associate-a-label-with-every-form-control

Shawn: The issue with this is that in some cases there are red x and green check that distinguish good from bad. Not all examples have that dichotomy. So the i was used to designate examples that do not have god/bad parts.
... There was concern that the i might mean more information and be clickable.

<Vicki> second that

Sharron: I had no idea what it was, just wondered what it meant.

Brent: I assumed that i meant information but did not assume it was clickable. I like the colors better than in black and white. I am fine with using the i, only objection is that the i is taller than the surrounding text. It should be the same size as other capital letters used for this purpose.

<shadi> +1 to brent

<shawn> +1 to vicki

<George> +1 to Brent

Vicki: I did try to click on it, looked around and figured out what it meant in context. It is not clear on first glance.

James: Why not just use the checkmark if it is a good example, even if there is not a bad side of the example. And then adding an icon that looks like rendered as opposed to code snippet.

Lydia: I expected and associated it with "information." Should we use a legend that explains the icons?

Shawn: Let's look first on the Designing and Writing page, Kevin is there any reason not to change the i's to checkmarks?

Kevin: No reason, probably OK

Shawn: What about on Developing?

Kevin: it is a bit different...

Shawn: Could we look at an option on Font Awesome?

<Brent> I like the checkmark to replace the "i" and I feel it could work in the developing page as well. I like James' idea

Kevin: I can rework one I found there, and could do it today or Monday morning

Howard: I think the i gets particularly confusing because other icons are consistent with use in many places, no problem. The i is used differently. I like James idea to use the checkmark. It becomes an unconsious indicator of good practice.

<davidberman> +1

Shadi: I like it as well, even in the rendered code. We can get rid of the i , replace with the checkmark and have no need for another icon.

<davidberman> no objection

RESOLUTION: IN Designing and Writing, replace i with checkmark.

Shawn: Two options in Developing - for "rendered" use the checkmark -OR- take a bit of effort to find another icon. Kevin?

<davidberman> me +1

<George> +1 Check mark

Kevin: Using a screen type icon would be more communicative but the checkmark is easy. So I am OK either way.

James: I want to advocate for the checkmark because it is consistent and the fewer icons the better.

<Howard> good point

<davidberman> + 1 for checkmark, with additional argument that "i" is Anglo-centric

<Brent> +1 to checkmark in Developing

<Vicki> +1 for checkmark

David: Checkmark is universal, not anglo-centric, I am in for the checkmark.

Shawn: Anyone opposed?

Shawn: no one opposed, I will go on record that I do not like the check mark, especially in isolation for those who may only look at this page. We can keep it as low priority for later, and I won't object. Checkmark means "this is good" but that doesn't fit with these rendered examples

Howard: I don't really like checkmark either in this context. Especially given the fact that code snippet has a unique icon, the rendered code should as well in relation and reinforcement of the meaning.

Shadi: Process wise, could we not publish and make the change when and if we find the perfect icon?

Shawn: yes, we can publish a first version next week and continue to refine. So I would like to keep this as a low level priority but not hold up publication.

Shadi: I like the proximity, the "good" explanation is clear, there is an increase in cognitive overload in introducing new icons.

Sharron: Howard's point resonated with me. Kevin said he could find alternative. Maybe wait until then?

David: I am in agreement with Shawn, I agree now that there is a better option out there and happy to release as is with the better solution to be put in place as soon as it is identified.

James: If we start needing more of these type of examples, some have grey bar with icons and some do not.
... if we need more variety of icons, the grey bar decision will have impact.

Kevin: To change to using the tick icon instead of the i is easy, the trade out of the rendered icon is more complex.

<shawn> without gray bar at top http://w3c.github.io/wai-quick-start/designing.html#ensure-that-form-elements-include-clearly-associated-labels

Shawn: James second point is that there is a grey bar at top, some don't

Kevin: The ones with no grey bar are those that do not need a caption or need of clarification about what the example does.

Shawn: Option would be to add caption with redundant information? If we decide each example *should* have a bar, would we be adding unecessary and unimportant information?

Kevin: It would still potentially highlight this is good, but the extra information would not have real significance

Howard: I at first agreed with James but on examination, it seems consistent and there is no problem, no need to add unecessary info.

James: I don't necessarily think the caption would be redundant or even unimportant but coould be clarifying. I am a bit conflicted because I don't like adding "stuff" but I do like parallel structure. Could use the grey bar to specify what this example is doing.
... why this particular example was created.

<shawn> example http://w3c.github.io/wai-quick-start/designing.html#provide-alternative-text-for-images

Shawn: Looking at this one, Howard has pointed out that one this one there is descriptive text in the example box itself. Maybe should be handled differently.

<kevin> [Note there is also descriptive text in the Create designs for different viewport sizes example]

Shawn: we decided to leave this as an open issue, not to delay publication, but just to be aware. I propose that we leave as open issues and then the question is are we comfortable publishing and leave it on the todo list?

<Vicki> +1 james

<George> +1 james

James: Agreed that we can move forward, this should nto be a show stopper

<davidberman> +1 (I am eager to see what target audience thinks of it all, before we keep tweaking)

<Howard> +1

Shadi: is this something that the editor can take as Editor's discretion?

Shawn: Everyone is fine with leaving it for first publication, with the understanding that editor will come back with a proposal based on this input.

<scribe> ACTION: James to create GitHub issue on greybar issue [recorded in http://www.w3.org/2015/09/25-eo-minutes.html#action01]

<trackbot> Created ACTION-332 - Create github issue on greybar issue [on James Green - due 2015-10-02].

RESOLUTION: OK to publish with checkmark for rendered code with understanding that open issues will include this icon and "grey bar issue"

Browser testing

Kevin: I have tested, I run on a Mac on Chrome, FF, Safari. I am struggling to test sufficiently on IE. Can others of you test v3 on IE?
... if we can get broader browser testing that would be useful. Volunteers to do that?

Shawn: I can do IE 9 and 10...who else?

<Vicki> I can

<davidberman> We have IE9 on Windows7 we keep around for such testing.

<George> I can do 10

James: Are we also doing screen reader testing?
... I can have some folks on my team do that.

Vicki: I can do IE 9 and 10

David: What is the standard, what is our browser basket? Is IE9 even relevant any more? Does W3C or WAI have a standard for the entire presence?

Shawn: We do not have published standard.

David: Sounds like something we really should have.

James: Related to my question bout screen readers. Here we don't use VO but JAWS due to market share.
... I suggest we draw that line in the sand and test to that.

David: But we are part of a larger animal, don't we conform to the broader standard that is w3c.org-wide that is formally defined somewhere? Do we have a record of that?

Shawn: I will check on that.

Kevin: Will you raise an issue on GitHub when those are found in testing?
... anyone using IE 11?

Shadi: I have a version somewhere

Shawn: Please raise issues on GitHub.

Overview page

<shawn> http://w3c.github.io/wai-quick-start/

Shawn: Suggestion is to present only the top row with no additional info about work in progress, any objections?

All: None

Contribution panel

<shawn> https://github.com/w3c/wai-quick-start/issues/266

Shawn: We will continue to refine the acknowledgements to all who contributed. It is a broader issue than just on this specific deliverable, there will be a more specific chance to coment when Kevin's connectivity improves. Comments, questions?

Publication Plan

Shawn: As we address these relatively minor issues, are we ready to announce next week?

<shawn> +1 to publishing first version next week (as we continue to refine)

Sharron: Yes, please let's announce next week

<Vicki> +1 Shawn

+1

<Lydia_Harkey> +1

<George> +1

<Howard> +1 to announcing

<Brent> +1

<kevin> +1

<James> +

<davidberman> +1

<James> ...

<James> +1

<shadi> +1

Approval to publish survey

<shawn> https://www.w3.org/2002/09/wbs/35532/EOWGTipsPublishSept2015/

Shawn: We drafted a survey to be released pending the outcome of this meeting, basically asking if you are OK to publish, anything that you want to raise as an objection that prevents publication, and finally anything you want on the list for future tweaks?

Shawn: take a look, answer the survey now if you'd like and we will have on record.
... If you add an issue in GitHub that does not have to be addressed before publication, use the milestone widget to mark it as a Phase 2 issue.
... any other comments? We will barring any other objections, we will send the publication notice to WAI-IG and once that is posted, please feel free to spread the word and let the world know about your good work. Any questions?
... than we all lift a celebratory beverage of choice on next week's call.

Priorities

Shawn: Within Work for the Week (if you have more time) you see EasyChecks, Showcase with Videos, QuickRef, Roadmap etc. We have several things still in draft status, and would like to get them published. Our proposal is to complete these resources, publish them before we return to the Tips. Discussion, questins?

<Brent> I agree with that approach

<George> I agree

<shadi> I agree

<James> agreed

David: agree

<davidberman> +1

Shawn: are there any concerns?

Kevin: Does that include the Policy document?

Shawn: I will let you and Shadi determine how that fits in.

RESOLUTION: Prioritize RoadMap, Planning and Improving before next batch of Tips.

Easy Checks

Shawn: Easy Checks was in a nearly complete draft. We have recently reviewed the open issue and addressed them. We had some suggestions for a new checks which has been drafted. The question on the table is does it meet the criteria, have issues been sufficiently addressed? Did not intend to reopen the document for wholesale revision.

David: I would like to do edits, such as a marked up wiki to address the things I found with fresh eyes.

Sharron: In the field I find that many people are using Easy Checks. I would very much like to know what fixes are absolutely necessary to get it to publication and out of draft status. Anna Belle and Eric have reviewed the illustrations and I think have resolved some minir outstanding issues.

<George> :)

David: Will put my issues in GitHub and limit to those that are most important.

main EOWG mailing list and wai-eo-editors list

<shawn> w3c-wai-eo@w3.org

<shawn> Has 100-ish subscribers, including all active EOWG participants, many past participants, and many lurkers. We use this list for messages that all active participants need to read.

<shawn> wai-eo-editors@w3.org

<shawn> Currently has chairs and active editors. Any active EOWG participant may also be subscribed to the list (and probably anyone else who wanted the e-mail clutter, too :). If you want to be subscribed, just let me know.

<shawn> We use 'wai-eo-editors' for exchanges that we want to be easily-reference-able and public, yet do not need to clutter the main 'w3c-wai-eo' list. For comparison, GitHub comments and survey responses don't go to the main EOWG list, yet are very important.

Shawn: Main list EOWG for those that everyone needs to read but most nitty gritty detail discussion is on wai-editors
... is that clear?

David: Yes, don't see a need for me to subscribe to wai-editors

<George> great info!!!

congratulations

Sharron:Just wanted to take a minute before we adjourn to thank Shadi and Kevin for the Tips - they are a great addition to the WAI resources and to thank all of you who put in the time for careful reading and great suggestions for improving them as they were created. Good work all!

<shawn> Thanks for the work!

<davidberman> +10000000

<Lydia_Harkey> Ditto!

Shawn: Good work everyone on the Tips, have a good week, thanks!

<davidberman> thanks for great stewardship, oh fearless leaders!

Shawn: next week's work will be a bit easier, mostly review of what's next.