[IxDA Discuss] help text in input fields - bad?
Use instruction text on the control when space is a concern. Ensure that the instruction text conveys the purpose of the control. For example, 'Search email' in yahoo specifically searches the inbox and not the web . Do not display critical instructions that the user needs to see when using the control. Using colors may cause some readbility issues for color blind or elderly participant. It should be ok, as long as the content is accessible even when the styles or color is turned off. Let me know your findings regarding the use of color. -Suba On Tue, Feb 2, 2010 at 10:29 AM, Jayson Elliot jayson.ell...@gmail.comwrote: Does anyone have research to point to regarding the practice of placing instructional text in a field that is meant for user input? For example, on a site like http://www.huffingtonpost.com/ you see Google custom search inside the search field; or http://www.adobe.com/ writes Search Adobe.com inside theirs. Welcome to the Interaction Design Association (IxDA)! To post to this list ... disc...@ixda.org Unsubscribe http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help .. http://www.ixda.org/help
[IxDA Discuss] Browse or Search
A music site should attract not just the primary users who knows what their goals are (what they want to listen to and buy), but also the general audience who are not always familiar with the new artist or the playlist. Scanning the list by names, their images or listening to sample of their songs helps to make a decision. I would propose displaying search as a primary functionality and a 'Browse by Artist or catagory' link below the search to cater to the needs of wide range of audiences. Suba Welcome to the Interaction Design Association (IxDA)! To post to this list ... disc...@ixda.org Unsubscribe http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help .. http://www.ixda.org/help
Re: [IxDA Discuss] Alternate design for check box table
I don't claim to know all of the PC keyboard shortcuts. However, I'm aware of the traditional Shift + click and Ctrl + click to select multiple items. This behavior is used in applications like Microsoft Outlook and also in windows explorer to select multiple files. Yes, there is no visual clue or good affordance. It wouldn't have normally occurred to me to try shift+click in a table where the rows have check boxes because the natural tendency would be to directly select the check boxes. I am not sure if it was a conscious design decision or an artifact of the software implementation. Letting people know visually or at the least through help documents would benefit users. On Tue, Sep 16, 2008 at 1:14 PM, Meredith Noble [EMAIL PROTECTED] wrote: I had the exact same issue and sadly decided to go with the standard checkbox approach, because my client's customers were already used to that style of interaction, and because I couldn't come up with anything else that worked well with the number of batch actions I had. Couldn't you enable both so they can learn the interaction over time? The Hotmail model, yeah, absolutely. I just tried it out with Shift+Click and Ctrl+Click and it's great; Fitt's Law at its best. But it never would have occurred to me to try Shift+Clicking, and I never saw anything on the interface that suggested it might work that way. How did you discover it, Suba? If my client's developers weren't already going nuts, I might suggest it now... but perhaps I'll save it for phase 2. :) I'd put in a little help bubble explaining the feature though. As soon as I see checkboxes the idea of Shift+Clicking just doesn't enter my brain. Meredith Welcome to the Interaction Design Association (IxDA)! To post to this list ... [EMAIL PROTECTED] Unsubscribe http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help .. http://www.ixda.org/help
[IxDA Discuss] Formal design review process
How do you conduct design reviews at your company? Who generally signs off on the designs? What are the inputs/outputs for the review (wireframes, full interaction specification, etc.)? How about recommended books/templates/resources on this topic? -- Design reviews with the product development team are the most interesting and challenging activity. We use low-fidelity prototypes (that demonstrates sequence of interactions) during design reviews. A short review is first conducted with the design team or with couple of co-designers to get feedback on the designs. This also gives the designer a chance to check if he has adequate convincing explanations for why the designs/interactions are designed in a certain way. During the design review with product team, the designer leads the session telling the story explaning what the product requirements are, the different concepts he came up with, scenarios where some concepts wouldnt work and what his final concept is. The team might accept the design or propose changes and the designer should be prepared to answer why the changes would work best or wouldnt work for the user in a given scenario. A final verbal agreement is made between the product lead and the designer at the end of the session. There might be list of changes to be made to the design or the design might be agreed as the final design. The meeting notes, agreement or proposals are documented somewhere at the bottom of the wireframe so the team can look back at any stage during the cycle and recollect why such decisions were made. -Suba Periyasami Welcome to the Interaction Design Association (IxDA)! To post to this list ... [EMAIL PROTECTED] Unsubscribe http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help .. http://www.ixda.org/help
[IxDA Discuss] Best practices to evangelize UX design?
What are some of the strategies that you have used to evangelize UX and usability practices in your company? The following are some tips that I think works Showing videos of users frustrating experience with the product Measuring user experience of the new design and publicizing (using wall posters or by blogging on the web site) how improved the product is for the user. Anything you can add ? -Suba Periyasami Welcome to the Interaction Design Association (IxDA)! To post to this list ... [EMAIL PROTECTED] Unsubscribe http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help .. http://www.ixda.org/help
[IxDA Discuss] List vs. Wizard
I don't have any solid user data on this. However, we redesigned a major web application and used both list and wizard view. Use wizard patterns only when the application is complex enough and users have to complete the task in a specific order. Our users (IT administrators) preferred to view information in a list rather than a wizard because of the ability to add/manipulate the information quickly -Suba Periyasami Welcome to the Interaction Design Association (IxDA)! To post to this list ... [EMAIL PROTECTED] Unsubscribe http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help .. http://www.ixda.org/help
[IxDA Discuss] web app messaging
The biggest issue is that on a page with 15 items, the user could be scrolled half way down the page, so putting the messages at the top(like gmail) doesn't really work. --Here's an alternate thought Have an action area and a content area. Place the list items in the content area and make the content area scrollable. Place the action area below the content area or along the side of the content area. The user can scroll the content area that has the list items and take any actions on the items. Once an action is performed, the action area becomes active and displays feedback/error messages. User can also undo or perform other actions in the action area. Have the action area as a expand/collapse panel. This will allow to display more list items when the action area is not active. Provide a prominent link in the action area if there is a need to see all actions that have been taken on the list items. Clicking this link should take the user to a web2.0 translucent page (as John suggested) that would list all the actions that the user has performed in the past. -Suba Periyasami Welcome to the Interaction Design Association (IxDA)! To post to this list ... [EMAIL PROTECTED] Unsubscribe http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help .. http://www.ixda.org/help
Re: [IxDA Discuss] Design Deliverables and Developers
On Wed, Mar 5, 2008 at 3:52 AM, Stew Dean [EMAIL PROTECTED] wrote: On 04/03/2008, Celeste 'seele' Paul [EMAIL PROTECTED] wrote: Does anyone know of studies or other research that explicitly looks at how developers are using design deliverables in practice? Particularly integrating things such as wireframes in to functional specifications. Or even if developers get the wireframes and mockups we give them. I've found that developers prefer annotated slides or a big numbered list of issues to having to read anything big, but those types of things don't look as nice as a fully written final report for the project manager. Thoughts? ~ Celeste I found the book Communicating Design http://www.communicatingdesign.com/ to be useful. In our company, during initial brainstorming meetings, we involve the developers and discuss the design. They are also the product experts and will usually have a lot of feedback to give us. Based on the discussions and feedback, we develop screen designs and get an agreement on the design. We then use the screen designs and create html mockups and include detailed documentation that lists how the links will behave, what components are disabled, what page will launch when a button is clicked, is it a action button, how a show/hide button helps the user and so on. Documenting the decisions we made is important so we can look back at the end of the project and recollect where we made important decisions and why the design looks and behave in a certain way. We made it a practice to even document the original design and alternate designs we came up with and why it was rejected by the product development team. This helps us to recollect what tasks need to be tested or answer any questions that executives/users have during or after the release. Finally, before handing the document off to the developers, we review the document with a teammate or with a member in the development team who we can trust. This will help us to make sure if the design is explained clearly and information is organized well. In our company, the QA uses this design spec to test the product interface. If there are multiple audiences for the document, organizing the content in to different sections and indicating who should care about this section (using visuals cues like different people icons for developers, project managers and so) will help people to ignore stuff that is not relevant to them. Welcome to the Interaction Design Association (IxDA)! To post to this list ... [EMAIL PROTECTED] Unsubscribe http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help .. http://www.ixda.org/help
