RE: [WSG] new yahoo user interface library
ACE. nuf said. ta heaps. benwg *while worshipping from his knees* From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miles TillingerSent: Wednesday, 15 February 2006 12:02To: wsg@webstandardsgroup.orgSubject: RE: [WSG] new yahoo user interface library I am in awe! I'm yet to score a commercial excuse to implement an AJAX solution, but I've been playing around with scriptaculous and other frameworks. This offering from Yahoo is just amazing and looks to provide yet more functionality. I'm sure this will be appreciated by everyone who is lucky enough to use it! Thanks, Miles. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted DrakeSent: Wednesday, 15 February 2006 4:28 AMTo: wsg@webstandardsgroup.orgSubject: [WSG] new yahoo user interface library Hi All As you may know, Yahoo has been hiring some very talented web developers over the past year, not to mention purchasing great companies like flickr and de.licio.us. Now, they have opened that wealth of talent to you for free. Yes, I’m pimping my bosses. But seriously, this is really good stuff. They’ve released an open-source platform of standards-based code snippets and best-practices. Many of these are similar to other projects out there. However, Yahoo has taken the time to make sure they scale to millions of hits and pass privacy scrutiny (now stop typing the China related snickering), I’m talking about making sure there are no memory leaks or possibly passing along less that secure protocols. Further, the library discusses the JSON data transfer protocol. So, enough of the sales pitch (I had nothing to do with this project.. but I plan on using it!) visit the http://www.yuiblog.com/ yahoo user interface blog and learn how to use these advanced programming techniques. Ted Drake Front-end Engineer Yahoo! Tech IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
[WSG] Attention STDS Managers / Strategists :: Visual baseline management technique
G'day from australia boys and girls. This ones for the large organisation scale Managers / Strategists among us. I am of course starting with the presumption that we are all using some form of visual baseline to handle the management of our visual assets (imgs, css etc..) within our respective environments. Also knowing that there (also presumably) is a web standards strategy in place to handle the application of those assets to the applications / sites that use them. Regarding the management of changes to the baseline. Eg. New interactive device creation to handle a specific interactivity requirement has to be created and added to the baseline to allow its implementation into a specific intranet web product. What are your thoughts on governing of the inclusion of the new device with respect to: - Maintaining multiple devices which meet the same need, where multiples are needed for issues of technical capability or other requirement. (assuming that the visual assets are distributed to multiple development / deployment platforms) - Cataloging of the assets within the library, and exposing that catalogue to the systems designers and more importantly to the interface design teams. - handling the removal or deprication of a device from active duty. - conversation about any other issues you may have encountered as related to this topic. BenWG Peace out, or out in pieces Where do you want to go today? Notice: The information contained in this e-mail message and any attached files may be confidential information, and may also be the subject of legal professional privilege. If you are not the intended recipient any use, disclosure or copying of this e-mail is unauthorised. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete all copies of this transmission together with any attachments. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] "cool" FAQ page [follow up]
True. But I wasn't talking about disabling any features at all.
And if the toggles are done correctly I understand that the find
functions will still behave correctly, because the headings will have
appropriate key words in them anyway. Presuming of course you have them
written descriptively.
One could also argue (for the sake of it) that if your toggled page
extends so far as to warrant a large anchor listing at the top of the
page, perhaps the information segmentation is not quite up to scratch
either.
To me, the core of this discussion revolves around there not being one
way to skin the cat here. (apologies to any cat owners) Which simply
reinforces the case for web standards that are constructed in a modular
fashion to facilitate delivery of information in varied formats to
accommodate for the intended user groups.
benwg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Samuel Richardson
Sent: Tuesday, 7 February 2006 12:53
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] "cool" FAQ page [follow up]
Just because a large subset of your users don't use a particular
function on your web browser is not a good justification to disable its
use.
If a larger number of your users are skimming the headlines then
clicking to find more details about a particular entry then post a
series of anchor links at the top of the page that jump down to the
required content. This is a: a fairly standard way of doing FAQs on the
web and b: doesn't stop various browser features from working.
WINTER-GILES,Ben wrote:
>I'd have to challenge the statement about users normally using the
>browsers find feature.
>
>The majority of users that I have (or had rather) to accommodate for,
>didn't even know that their browser had a find feature. Instead
>preferring to use scroll and skim behaviours to locate information.
>
>Not wanting to debunk what you were saying, of course, but I think it
>would be less than complete to band everyone into the group that
>actually know that Ctl+F finds things within a page.
>
>The most recent iteration of FAQ's that we implemented had toggles
>delivered via css / div. but that said, we also included a find /
>search field to help expose what was hidden. Additionally we used a
>well versed information architect to review our headings and ensure we
>were using appropriate terminology to head up each FAQ.
>
>Feedback on that implementation was generally positive.
>
>That said the target user group was internal, and 40+ female
>administrative / data worker from a mainframe background and NOT the
>general public.
>
>I have not located detailed ebehavior reports addressing the "find"
>option within the more global public. Does anyone have this data?
>
>Ben Winter-Giles
>Interface Design Manager
>DEWR.gov.au
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of R Walker (RMW Web
>Publishing)
>Sent: Tuesday, 7 February 2006 12:25
>To: wsg@webstandardsgroup.org
>Subject: Re: [WSG] "cool" FAQ page [follow up]
>
>A big reason for not using "toggles" for FAQs we found was the
>inability to use the browsers "find" ("Find in this page") feature.
>Often the reason for using toggles is that the page's content is quite
>large. Users would normally us their browsers find feature to jump to a
>keyword they are looking for. If that search result is in a hidden
>element the browser will not show it - making the page less usable.
>
> Also it is helpful to use anchors on each Q & A (esp. if you have
>Customer Service Reps directing users to the page). To make the page
>more useful, you could allow for bookmarks and emailed URLs to expand
>an answer by checking the URL 'hash' for the related question.
>
>--
>Rowan Walker
>RMW Web Publishing
>http://www.rmwpublishing.net
>**
>The discussion list for http://webstandardsgroup.org/
>
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
>**
>
>
>Notice:
>The information contained in this e-mail message and any attached files
>may be confidential information, and may also be the subject of legal
>professional privilege. If you are not the intended recipient any use,
>disclosure or copying of this e-mail is unauthorised. If you have
>received this e-mail in error, please notify the sender immediately by
>reply e-mail and delete all copies of this transmission together with
any attachments.
>
>
>**
>The discussion list fo
RE: [WSG] "cool" FAQ page [follow up]
I'd have to challenge the statement about users normally using the
browsers find feature.
The majority of users that I have (or had rather) to accommodate for,
didn't even know that their browser had a find feature. Instead
preferring to use scroll and skim behaviours to locate information.
Not wanting to debunk what you were saying, of course, but I think it
would be less than complete to band everyone into the group that
actually know that Ctl+F finds things within a page.
The most recent iteration of FAQ's that we implemented had toggles
delivered via css / div. but that said, we also included a find / search
field to help expose what was hidden. Additionally we used a well versed
information architect to review our headings and ensure we were using
appropriate terminology to head up each FAQ.
Feedback on that implementation was generally positive.
That said the target user group was internal, and 40+ female
administrative / data worker from a mainframe background and NOT the
general public.
I have not located detailed ebehavior reports addressing the "find"
option within the more global public. Does anyone have this data?
Ben Winter-Giles
Interface Design Manager
DEWR.gov.au
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of R Walker (RMW Web
Publishing)
Sent: Tuesday, 7 February 2006 12:25
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] "cool" FAQ page [follow up]
A big reason for not using "toggles" for FAQs we found was the inability
to use the browsers "find" ("Find in this page") feature.
Often the reason for using toggles is that the page's content is quite
large. Users would normally us their browsers find feature to jump to a
keyword they are looking for. If that search result is in a hidden
element the browser will not show it - making the page less usable.
Also it is helpful to use anchors on each Q & A (esp. if you have
Customer Service Reps directing users to the page). To make the page
more useful, you could allow for bookmarks and emailed URLs to expand an
answer by checking the URL 'hash' for the related question.
--
Rowan Walker
RMW Web Publishing
http://www.rmwpublishing.net
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Notice:
The information contained in this e-mail message and any attached files may
be confidential information, and may also be the subject of legal
professional privilege. If you are not the intended recipient any use,
disclosure or copying of this e-mail is unauthorised. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete all copies of this transmission together with any attachments.
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
