See also: IRC log
<scribe> Scribe: Doyle
<scribe> ScribeNick: doylesaylor
Shawn: Let's get started.
Shawn: Thanks for the comments Ian.
Ian: yea or nay on the comments? And I'll submit.
<shawn> bottom http://lists.w3.org/Archives/Public/w3c-wai-eo/2010JulSep/0017.html
Shawn: Go to bottom to the
notes.
... Teleconferences do not always represent a consensus. Gives
time for persons who weren't in the teleconference.
... lets take a look at Ian's comments.
... on the first one for the abbreviation. We thought it should
be abbr in several places in the document.
<shadi> <acronym>WAI-ARIA</acronym>
Shadi: I think the entire document is WAI-ARIA and does not need expanding, even someone who lands in the document anywhere their being there would be related to WAI-ARIA. I would use the acronym element without title attribute so it would not be read out every time, and not show in most browsers as an acronym. I don't know if that coding has any use, but it is still marked up as acronym.
Liam: I think it is taken as a pronounciation cue.
Shawn: I think it does. If it doesn't have the title most browsers won't distinguish it?
Ian: that's right.
<shadi> s/not abbreviation/without title attribute
<IanPouncey> " * For instances of the abbreviation after the first in each section markup as a <abbr/> without a title attribute"
<sylvie> hello I am in a noisy environment today so i'll stay muted
Ian: changing the second bullet.
Shawn: I think what you want to say is; what Shadi proposes, WAI-ARIA is explained in the title in the H1 and the title is not needed elsewhere - to avoid clutter do not include the title attribute and any other abbreviations. What you want to say.
Ian: I would prefer that each section have an abbreviation.
Shawn: we discussed last week also.
<IanPouncey> "After the first use in each section do not markup WAI-ARIA as an <abbr/>"
Shadi: there is a bit of overkill about that abbreviation. I caught in several sections and it is in many places. In some of the references. Have in one paragraph two or three instances, a first occurrence in a sub section is ok.
Ian: in a sub section?
Shawn: you can mark up as an abbreviation but not as a title.
<shadi> #1. use abbr elemenet for each occurrence
Shadi: also don't use as a title in the text. The very first heading of the page the H1 right at the top.
Ian: We have the problem of rich applications for WAI-ARIA.
<shadi> #2. use title attribute ONLY for first occurence in a section
Shawn: Shadi?
Shadi: I think that is a different one if WAI needs expanding a short name for Accessible rich application. The WAI does not need an expanding.
<shadi> #3. do not use title attribute if name is already expanded in text
Shawn: we just need to get number 3. Attribute only. Ian see the 1 2 and three?
Ian: Yes.
Shawn: anything else?
Ian: I think WAI should be expanded.
<IanPouncey> WAI-<abbr>ARIA</abbr>
Shawn: In this case we actually never say WAI Rich Internet Applications. It really is an abbreviation. If you spell it out, it is still ARIA Accessible Rich Internet Applications.
<shadi> no <abrr>WAI-ARIA</abbr> or <acronym>WAI</acronym>-<acronym>ARIA</acronym>
Ian: Ok.
Shawn: Not ideal but are we ok?
<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010OctDec/0012.html
Shawn; we are set on that one. Back to Ian's draft emails. Comments?
<shadi> +1 to "non-disabled users" -> "using a visual browser"
<LiamMcGee> +1 ditto
<IanPouncey> "We felt that in places marking up WAI-ARIA as an abbreviation in every instance was causing a great deal of visual clutter, the last paragraph of 1.1 is a good example of this where the term is used 7 times.
<IanPouncey> * Use abbr elemenet for each occurrence, but only use title attribute for the first in each section
<IanPouncey> * Do not use title attribute if name is already expanded in text
<IanPouncey> "
Shadi: couple of comments further down. On technology example. We there yet?
<shawn> "This content needs to be available in text form within this document." what about longdesc
Shawn: Let's look at longer description for figures. You have could be long desk for this document but could be outside? Yes. Content needs to be available in text form.
Ian: Originally long desk.
... we skipped over the WAI-ARIA link. Is that ok?
Shawn: yes
Ian: We drafted replacement suggestions.
Shawn: you got several for that.
Shadi: first is to expand the full name PWD use the web.
<shadi> http://www.w3.org/WAI/intro/people-use-web
Shawn: for Ian to use in the comments. We try to write out to not use PWD in written publications.
Shadi: that is where the final draft will be published.
<shadi> [[which is currently being updateded by EOWG]]
Shawn: we purposely made that link publishable. For further comments in EOWG, go ahead PWD use the web. It is a referencible link.
Shadi: Could be updated by EO rather than when it is completed. Available soon that is wording nuances for editors discussion.
Shawn: we said last week we didn't have time and wanted to coordinate with Shadi, is on the agenda in November.
<IanPouncey> "For 4. Important Terms we would like to give further input on the AT section based on documents EO is currently writing. Additionally we would like a link to 'How people with disabilities use the web' which is currenlty being updated by EOWG (http://www.w3.org/WAI/intro/people-use-web) and which will be available shortly."
Shawn: I talked to Michael the staff contact and he said there is some flexibility if they get a comment next it would be fine, but in three weeks they plan to move on.
<shawn> For 4. Important Terms we would like to give further input on the AT section based on documents EOWG is currently writing. Additionally we would like a link to 'How people with disabilities use the web' which is currenlty being updated by EOWG: http://www.w3.org/WAI/intro/people-use-web.
Shawn: Anything else on that
one?
... next one host language semantics. Document focus?
Ian: we talked about this, do we want to include in the comments?
Shawn: Instead of consideration given, we want to say some EO participants the scope of this should be focused on what developers want, and the User Agent comments in the User Agent guide.
<shawn> "we feel that this separation may make it more accessible to the target audience" -> "we feel that this separation would make it more usable for the target audience"
Ian: replace that sentence?
Shawn: the second part of the sentence.
Ian: ok
<Zakim> shadi, you wanted to propose new comment on definition markup/styling
Shawn: Anything else on document focus. Style consistency Shadi?
<shawn> consider using styles from recent WAI TR documents
Shadi: Style consistency, brings the question, for all documents? No. To avoid that we want to make the point, re-using styles. To recommend that. One comment. I have a couple more.
<shawn> consider using styles from recent WAI TR documents, such as WCAG 2.0
Shawn: consider using styles from WAI WCAG 2.
Shadi: or consider using styles from WCAG 2.
Shawn: the one that jumped out at me, was the term analogy one.
Shadi: when you click a term when it is black it is hard to select again that is already visited is hard to make. Regardless what style they use that should not happen.
Doyle: I agree with that.
Shawn: yes.
Ian: in the same section?
Shawn: they may still do that, it is egregious we should point that out.
Ian: belong in style consistency?
Shadi: call the section style. One on consistency and so on. One thing Style for the notes is quite gray. Check color contrast on that?
Shawn: It's fine. I'll give you a number in a bit.
Shadi: It is still quite gray.
Shawn: they still should have
good reason to use WAI-ARIA styles. I will go to them and we
will address it. I imagine they will say oh that is ok we'll do
it. Michael felt the Authors Guideline needs some help. So we
will work on that later.
... Ian more time?
Ian: making it hard to distinguish in the links.
Shawn: the definition links are italicized in green. And other things are italicized one could say there is not sufficient color coding.
Ian: Quick glance everything I see italicized is also green links.
Shawn: the main thing is to get it recorded as an issue.
Ian: is that acceptable?
Shadi: yes to me that is acceptable.
<Zakim> shadi, you wanted to go back to the acronmy markup comment
Shadi: to go back to the initial comments on the use of acronym. We mostly talk about the WAI-ARIA expansion. In general use the same principle for acronym after WAI-
Ian: that is part of the solution. Put in a follow this principle.
Shadi: that would work for me.
<IanPouncey> "follow this principle for other abrreviations and acronyms."
Ian: after the two solution bullets.
Shawn: anything else comment? Ok to send for Ian.
Ian: I will email them now, if anyone wants to take a quick look.
Shawn: It would be fine to send if you have a note on the bottom. Anything else?
<suzette> sorry have to leave now - see some of you next week.
Shawn: Shadi sent some issues in email.
<shadi> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010OctDec/0016.html
<IanPouncey> need to step out for a minute, brb
Shadi: Thank you for comments.
The email is linked from that and is a summary of comments that
need discussion. Let's go down the list. The first comment from
Sailish. Using connected list, related sections. Basically in
most of the section there is always a related end. He suggests
not to use nested list. To use headings or bolded as another
paragraph. Liam suggested that. Thoughts?
... Nested lists are often not the most comfortable thing to
use. I would like to avoid using heading level. Overkill of
headings.
Jennifer: I agree.
Shadi: Bolded paragraph as a list level. Agree?
Shawn: I think just a paragraph to do bold and do spacing between stories of web users and the intro and the beginning of the list.
<shadi> ACTION: change nested lists in related sections to bolded <p>'s as list intros [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action01]
<shawn> +1 for leaving CMS
Shadi: ok gone. In the stories page. Let's focus on that page. In the section there called Mr. Jones. First story there. That talks about Content Management Systems. Second story. Talks about CMS get them into to highlight as one of these situations. The effect of them. The specific comment was that it was too technical. Shawn was for leaving here.
Jennifer: I am for leaving in.
Shawn: take out of the first sentence, where it might scare them off.
Shadi: have in the last paragraph. Would there be a disconnect?
Shawn: (states alternative)...tool is a CMS Content Management System. Take CMS out of the first sentence. YOu can still say but take out of first sentence. Put in the second sentence.
Shadi: Ok.
Jennfier: I am ok with that.
Shadi: move down a little bit and keep it.
<shadi> ACTION: soften down "CMS" by taking it out of the first sentence and putting it into a second one [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action02]
<shawn> something like maybe: Mr. Jones is a reporter who must submit his articles for an on-line journal using his publisher's tool. The tool is a content management system (CMS) that he can access via the web. Over his twenty-year career,...
Shadi: action taken. Staying there in Mr. Jones. The story talks about Mr. Jones RSI using the keyboard, using the keyboard would re-damage his hands. change to increase his pain. Liam agreed with that comment. An odd use that jumped out at him. I wanted to highlight it is not only pain, but to really say that ...
Jennifer: what about further damage?
Shawn: worsen?
Shadi: worsen what? Pain, damage, health?
Shawn; let's brainstorm for a minute.
Liam: deterioration.
Jennifer: acerbates.
Shawn: acerbates RSI.
Shadi: RSI is often progressive. Not only re-inflaming.
<shawn> EXACERBATE is : to make more violent, bitter, or severe
Shawn: to make more violent or severe defines acerbate.
Liam: worsens means the same as exacerbate.
<shawn> he would have to use a mouse instead of voice recognition or typing, and this would worsen the RSI
Shawn: worsen RSI.
Jennifer: works for me.
Liam: me too.
<shadi> ACTION: change to "would worsen his RSI" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action03]
Shadi: next comments from Jennifer. I will skip the one on the overview page. Staying on the story page. This was original title was scenario for users. The suggestion is to use stories throughout. We went a little back and forth if scenarios be a better term.
<shawn> This page outlines selected stories (scenarios) of people...
Jennifer: to be clear, on my comment. I still like the word scenario, I would like stories to be in there in and it would be odd to have the title and then not use further on.
Shadi: there are two uses of scenario. In the first sentence for example we could change that to stories. We could leave one as scenarios, and one as story. Used in the overview page as well. Michael in his comments agrees we should use throughout.
<Zakim> shawn, you wanted to suggest using BOTH "stories" and "scenarios" in the intro, eg This page outlines selected stories (scenarios) of people...
Liam: having come back to this I originally said to be consistent, but here scenario is used to clarify here I think that is fine.
<shadi> [[these stories outline scenarios of ...]]
<shawn> These stories are scenarios...
Shawn: something like using terms interchangeably, make clear in the first sentence. Fine what Liam said as well.
Shadi: something along that line.
Shawn: It don't need to have that outline, just these stories are scenarios....
Shadi: ok.
<shadi> ACTION: use "these stories are scenarios ..." to use stories and scenarios interchangeablly from the start [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action04]
Shawn: you say interchangeable?
In the intro and where else?
... you could take outlines out.
Shadi: let's go to overview page now. There were comments for there. The first sentence (Shadi reads) that is the opening sentence to draw people in. Jennifer and Michael were commenting on the flow or grammar of this. Liam suggested using a hypen or colon to break that up.
Jennifer: Liam's idea works for my suggestion.
Shadi: you were talking about the second sentence?
Jennifer: the third one.
Shadi: Michael felt it didn't flow for him. We'll take Liam's suggestion.
<shawn> —
Shawn: M dashes not hyphens.
Liam: you could use hairline spaces.
Shawn: would look really nice there.
<LiamMcGee> http://en.wikipedia.org/wiki/Dash
Liam: It is a very small space on either side that allows a line break. See link.
<LiamMcGee> U+200A
Jennifer: there is a way to code them so they do that.
<shadi> ACTION: use "m-dashes" with "hairline spaces" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action05]
Shadi: ok. disagree?
Shawn: I did kind of like the
pauses of the sentences. I'm thinking about the m dashes. You
want people to stop and think there.
... I think it is acceptable to be not grammatically correct in
a situation like this. I put in somewhere else to see what the
m dashes and that doesn't work in how we want people's brain to
processes that.
... who brought this up?
Shadi: Michael.
Jennifer: to fix my thing is simple to make that a full sentence and your are done.
<shawn> How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people have difficulty hearing or understanding, or have other accessibility needs?
Liam: You could put all people in. As the explanation.
Shawn: that is something to consider where we can choose not to have perfect grammar to get the point across.
<shawn> How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people who have difficulty hearing or understanding, or have other accessibility needs?
Jennifer: I can live with that. We are getting to how people would think that is the most important in the beginning.
Shawn: Shadi?
Shadi: added the word people?
Shawn: I took out another who.
Shadi: we did do a fair amount of the different kinds of disabilities without listing them. That affected the grammar. Live with that?
<shadi> ACTION: use "How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people who have difficulty hearing or understanding, or have other accessibility needs?" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action06]
Shawn: I think that is the way to do it. The non grammaticalness of it gets across the flow we want.
Shadi: moving on, to continue to
Michael's comments. Sylvie is next. There seems to be a little
confusion with the page contents.
... I am not sure how much is related to the first view and to
the page order. The introduction heading does not appear
visually, and invisibly in the page content. Using the style
sheet, select that link and see the page content. We removed
the links within the page content. The comment still is a H2
heading. To navigate to easily. Within the introduction. Anyone
having trouble navigating. Navigating by headings?
Jennifer: I didn't fiddle with the heading navigation too much. I thought the page was in transition and didn't want to bog down in that. I believe when you navigate, you expand all and go to heading is to the link collapse, that might be window eyes incorrect.
Shadi: change headings?
Jennifer: I think I had to arrow. It is not our responsible to accommodate there.
Shadi: the script is not good there either. Sylvie?
Sylvie: I think the problem I had with this after the introduction and then in somewhere in the page content and then the introduction and the contents.
Shadi: that is the organization aspect. So if we don't have the H1 have the heading and then after that page content.
Liam: I am looking for consistency with other documents.
Shadi: I think that is what Sylvie points out also.
<shawn> http://www.w3.org/WAI/WCAG20/wcag2faq.html
<LiamMcGee> suggest: Page contents as at: http://www.w3.org/WAI/intro/accessibility
Shawn: we do have things like WCAG FAQ. We don't call it page contents. I don't know if we have an invisible introduction there. Maybe if looking at consistency, maybe change the word page content. All right page content is floating there. In this case do we want the introduction to be first, and then this list on the page and not floating on the right because it is so long. Call it something besides page content?
Shadi: I looked at the FAQ it
does not have a heading there.
... change page contents to on this page?
Shawn: I don't understand?
Shadi: temporarily.
Liam: don't lose it because it is a good idea.
<sylvie> see for example eo page
Shadi: what are other ideas for page content.
Shawn: I was looking at the stories, you could say 'stories:' but wouldn't work for other pages.
Shadi: Sylvie writes EO
page.
... Let's stick with that idea. Stories on this page or
something like that. Diversity on this page?
Shawn: I think we want to stick to stories.
Shadi: thoughts or suggestions on this?
Shawn: I am looking to the others. No it doesn't work.
Shadi: using the flow approach we have to shorten quite a lot.
Shawn: remind me what you are thinking. There would be a separate contents list. To process expand all and collapse all. Fine for diversity users, fine for web browsers, for web principles, and for stories fine to use name, but not to focus on.
<Zakim> LiamMcGee, you wanted to hesitantly suggest more story-like headlines... e.g. Mr Lee goes shopping
<sylvie> other resource example :
<sylvie> http://www.w3.org/WAI/bcase/
Shadi: and principles is fine to use here. Ok with WCAG here. More story like headings? Look at later. Stay on page comments for a little bit. How about using on this page for now. Rather than page contents.
<shawn> On this page:
Shawn: works for me. On this page colorn.
Shadi: Sylvie points out business
case.
... On the business case the page contents comes before. The
issue though is the page content is loaded the right side.
Rolls up the side of it. The introduction floats between the
left navigation menu, and the page contents. but that is very
wide, and we can't have them side by side. They definitely need
to be moved. Liam says if we use story like headlines. Like Mr.
Egos shopping. For here?
Shawn: not for this draft, not
for this day.
... the other thing is these are stories, but realistically the
color blindness and the RSI are really the focus. Even though
the name is made to be realistic.
Shadi: the compromise solution is to use page content colon, rather than the heading? Agree?
<shadi> ACTION: use "On this page" as <h2> rather than "Page Contents" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action07]
<LiamMcGee> +1 agree
<shawn> example of superhead: http://www.w3.org/WAI/WCAG20/glance/
<shawn> how business case is done: Social Factors in Developing a Web Accessibility Business Case for Your Organization
Shadi: done. Couple more comments
from Michael. Michael proposes to use How PWD use the web.
Quote stories of users and then after that in H1 is not so
visible. To make smaller, my comment on that, it would be read
off screen readers first. Skipped more easily smaller.
... not a heading?
Shawn: It needs to be part of the heading you need the context if you land on this page. You need that context from somewhere else. What about I think it is not clear, generally we have the right idea. If people go around a lot, we don't want them to re-read business case every time. Take out the word draft, stories about disability users use the web.
Shadi: most readers should pause there.
Jennifer: one thing is that the page titles stay what they are. Good to stay so you know where you are.
<shawn> [ shawn suggests making the subtitle a bit smaller]
Shadi: I think when the draft is removed a little easier to focus. I am not sufficient taking Michael's idea.
Shawn: there are concerns with doing that way.
Shadi: yes subtitle a little smaller is good. Let me note that.
Shawn: If you have fonts that are different so confusion about 'are they the same or not' is minimized.
<shadi> ACTION: keep "how people with disabilities use the web" after page title [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action08]
Shadi: Michael commented on the
draft bracket on related resources, those links jump into the
middle of another document. To clarify where they are going I
put in brackets the section heading. Like in brackets hearing
seeing. There are issues with this. Issues with both captions
and transcripts jump to the same section. A confusing jump
between captions and transcripts.
... Going to the stories of web users page like Ms. Martinez,
third story. At the end of the story, something called related
sections within this resource. Under that there three bullets.
The second one is web browsing there are three items again, the
first one reads hearing seeing in open brakcets and then in
sign language.
Shawn: where do they actually go? The target?
Shadi: they both go to the same place in the Web Browsing section. To the top of the section. The reason why I didn't why I didnt' link into captions because it would really specific. There could be a second link to go to the top of that section.
<shadi> <a href="caption">caption</a> in <a href="section-top">hearing, feel, and seeing</a>
Liam: what is ... linking to the main section because they have no context?
Shadi: yes.
Shawn: I think it needs to be clearer though. When you click on this link you go to the section Hearing Reading Seeing. The part relevant here is the part about captions. What would the negative of having two links? Captions link in Hearing Feeling and Seeing link?
Shadi: that would be the thing to do. Objections.
Jennifer: An lot of links. Expand all those pages will have a lot of links.
Doyle: I agree
Shawn: I don't think you need to be for perceivable, and for hard of hearing, under accessible principles, the only page to add is the middle one is web browsing innovations.
Liam: even changing auditory dash hard of hearing. That way you have strong context and part of a larger section. Putting brackets is disambiguation and is not quite what we are trying to tell. them. In those cases you put auditory disabilities.
Shawn: It is how much you want to emphasize hard of hearing instead of auditory in general.
<shadi> ACTION: separate out link into section and sub-section [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action09]
Liam: yes.
Shawn: the next one, under web browsing navigation. Looking at the organization you might have Hearing Feeling and Seeing. Under that I don't know if that presents the information how we want it stressed.
Shadi: nest again?
Shawn: Just one idea, I am not saying this is the right thing to do.
Shadi: that is really the issue
here. You might want to read more about screen reader. If you
don't want to you don't want to link there, section first and
then sub section. Nesting approach might work. I'll take a pass
at that to see if it works out. From Jennifer. Expand I don't
know what to do about that. Reading the story talks about
screen readers or keyboard you want to read about that. The
headings Hearing Feeling and Seeing you won't see
... Anyone want to add anythig to this page? let's go to
Michael's last comment on accessibility standards. On the
principles page. Introduced first the components of
accessibility and the importance of standards. He proposes the
more important H3 and the sub sections called WAI Guidelines
used there. Support?
Shawn: I strongly support whatever the editor wants on this one.
<shadi> ACTION: add sub-section on "wai guidelines" in "accessibility standards" section [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action10]
<LiamMcGee> +1
Shadi: I will go along with that. Can people stay another ten minutes?
<shawn> link to http://www.uiaccess.com/accessucd/resources_videos.html ?
<shawn> could put after the list of pages
Shadi: last page, the comments on that to paraphrase to basically he is saying the resource used by teachers of design, the issue is they need more hand holding. go online they can use how to use the web in training videos. I think this could easily start growing. Developers would want to learn more not just teachers. An interim solution. Like online resources and have one or two, and other resources have more about this.
Shawn: first of all you don't have to put before the list pages, you can put after. I think we should consider this, who is the target audience, and most would get a lot out of videos and videos and other resources I think we should do.
Jennifer: I agree.
Shawn: we can discuss this some more Tuesday afternoon as part of our training discussion.
<shadi> ACTION: consider adding a small paragraphs to other resources on how people with disabilities use the web [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action11]
Shadi: to have specific resources exactly?
Shawn: do you want to call out to the list for specific resources?
Shadi: no, minimize efforts for this round.
<Zakim> shawn, you wanted to comment on suzette's comment and to request change to "Web browsing innovations" with next edit
Shadi: takes this to the comments, thank you all for the review and comments quite a step closer to the next stage.
Shawn: one more thing I request the title Web Browsing Innovations, be changed. I don't think of them as innovations.
Shadi: I am running out of ideas, I would appreciate suggestions?
<shadi> [[Ways of Browsing the Web]]
Shawn: how about web browsing? Or ways of browsing the web?
<shadi> [[How People Browse the Web]]
<shawn> browsing tools and strageties
Shawn: browsing tools and strategies?
Liam: that is right!
<shadi> [[Browsing Tools and Strategies]]
Liam: users strategies?
Jennifer: web browsing strategies.
<shadi> [[Web Browisng Strategies]]
<shawn> web browsing Approaches
Shadi: we talk more than about strategies. Web browsing approaches?
<shadi> [[Web Browisng Approaches]]
<LiamMcGee> [[what users do]]
Shawn: I like approaches better than methods.
<LiamMcGee> [[How users use]]
<LiamMcGee> [[How they do it]]
Shawn: other brainstorms on that?
Gone.
... thanks everyone who filled out the survey. Note we are
moving this forward. Try to schedule we want to have an ok for
review. We skip number three.
Shawn: Welcome to join the face
to face teleconference.
... Next the agenda is updated for the face to face. We will
look at the latest web redesign someone could step up and
review some of that information and introduce it?
Liam: I would be happy to do that.
Shawn: read through it good and introduce the topics and introduce ideas would be helpful.
Sylive: I am not sure what you mean?
Shawn: something about the agenda for the F2F.
Sylvie: an email to add suggestions for yesterday evening. Is the page the whole navigation?
Shawn: A list of all the pages we need in the site navigation. And it has a lot of new pages that have a new home, a question we can think about on the plane. Other ideas for pages to add? That was what that was for.
Sylvie: I counted 71 topics. I was surprised it was so larger a navigation.
Shawn: the site map has that many pages.
Sylvie: I thought the navigation bar?
Shawn: the site has all the pages, but the nav bar has the highest level. We will re-design. Thanks so I clarify what it is?
Sylvie: question about place? The conference center is big.
Shawn: I will ask and send you an email. At the end of this meeting.
Sylvie: ok.
Shawn: comments? Questions?
Jennfier: i am sorry I won't be there, I will look at over the minutes.
Ian: trying to have next week available poll.
Shawn: let's try next Tuesday to
discuss, for Friday to have a meeting. Decide on Tuesday.
Please keep updated availability survey. We use that a
lot.
... Use the current site map Liam.
Liam: the draft site map is not taking the current stuff?
Shawn: all that is from five
years ago. Something we looked at five years like a matrix we
don't want to do that. Not go into so much detail.
... have a good trip. See you next week.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/not abbreviation/without title attribute/ Succeeded: s/not abbreviation/without title attribute/ Succeeded: s/#2. use title attribute for first occurence in a section/#2. use title attribute ONLY for first occurence in a section/ Succeeded: s/Liams draft emails/Ian's draft emails/ Succeeded: s/ Shawn: gone Shadi?/ / Succeeded: s/ just these people are these scenarios./ just these stories are scenarios..../ Succeeded: s/ I am not saying this is the right thing to do./ Just one idea, I am not saying this is the right thing to do./ Succeeded: s/ I think editors discretion is what I want here./ I strongly support whatever the editor wants on this one./ Found Scribe: Doyle Found ScribeNick: doylesaylor Default Present: doyle, Shawn, +1.207.330.aaaa, Shadi, Ian, Liam_McGee, +1.650.348.aabb, jennifer, Sylvie, suzette, LiamMcGee Present: Doyle Shawn Ian Shadi Liam Jennifer Sylvie Suzette Regrets: Yeliz Alan Emmanuelle Andrew Got date from IRC log name: 29 Oct 2010 Guessing minutes URL: http://www.w3.org/2010/10/29-eo-minutes.html People with action items: ... add are change consider keep scenarios separate soften stories these use WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]