The web is primarily a visual medium with a little audio here and there. HTML5 supports the video and audio tags but our other senses have been shamefully neglected. Until now.

The W3C will shortly announce three new HTML5 elements which support alternative sensory interfaces:

• <texture> for touch
• <aroma> for smell, and
• <flavor> for taste

HTML Usage

The new elements will normally be used as wrappers for other items. For example, you might want to apply a fresh grass odor to an image of a field, e.g.

<aroma fresh="50%" sweet="20%" warm="35%">
	<img src="myfield.jpg" alt="field" />
</aroma>

The categorization attributes will vary depending on the tag, e.g.

• texture: smoothness, firmness, flaccidity, temperature
• aroma: sweet, pungent, acrid, fragrant, warm, dry, sour
• flavor: sweetness, sourness, saltiness

The volume and muted attributes are also supported to indicate the strength of odors and flavors.

However, unless you’re a chemical expert, defining these attributes isn’t easy. For that reason, all tags can use the src and type attributes to point to sensory definition files which contain one or more textures, aromas or flavors, e.g.

<aroma src="cheese.odor" type="stilton">
	<img src="stilton.jpg" alt="stilton cheese" />
</aroma>

Vendors will provide several pre-defined sensory packs within their browsers. However, Chrome’s representation of Roquefort is likely to differ from IE’s; it may be several years before we reach agreed sensory standards. Fortunately, it will be possible to develop your own definition files if compatibility issues arise.

CSS Properties

Textures, odors and flavors can also be applied from CSS. For example, our online cheese shop could link to a Stinking Bishop page:

<a id="stinking" href="stinking-bishop.html">
	<img src="stinking-bishop.jpg" alt="stinking bishop cheese" />
</a>

CSS could apply an appropriate aroma, flavor and texture as the user hovers over or focuses on the link. Sensory definition files or classifications can be used:

a#stinking:hover, a#stinking:focus {
	aroma: url("cheese.odor") stinkingbishop 50%; /* pack, type, volume */
	flavor: url("cheese.taste") stinkingbishop 98%; /* pack, type, volume */
	texture: 25% 30% 20; /* smoothness, hardness, temperature (degrees C) */
}

JavaScript APIs

JavaScript APIs will be available for the new sensory elements. For example, you could mute or change the volume (strength) of a sensory tag, e.g.

var cheese = document.getElementById("stinking");
var c = 0;
Pungent();
function Pungent() {
	cheese.aroma.volume = c + "%";
	c += 5;
	if (c < 100) setTimeout(arguments.callee, 500);
}

This example increases the cheese odor over time. Note that aroma-generating devices are likely to have slower response times than screen output: thorough testing will be required to ensure aromas and flavors don’t clash.

Hardware Support

Hardware devices which support these sense elements will be introduced during the next year. One of the first is a multi-sensory mouse by Ollofipra, the Scandinavian PC manufacturer. It uses a patented rubber mesh to change shape, texture and temperature. It also emits a range of smells and the central wheel generates different flavors. The company hopes to add the technology to touch-sensitive monitors so they become lick-able.

Please note that the W3C specifications for the sensory elements are at an early daft stage and implementation changes are inevitable. However, the future looks promising and the tags have potential to revolutionize web interfaces. You should certainly discuss it with your colleagues today.

Adverts pay for many of the resources we take for granted on the web. No one begrudges a few ads — you wouldn’t be reading this if you did — but some sites take adverts beyond a reasonable level. Google’s latest search algorithm change attempts to improve user experience by downgrading sites with too many adverts.

According to Google’s Inside Search blog:

We understand that placing ads above-the-fold is quite common for many websites; these ads often perform well and help publishers monetize online content. This algorithmic change does not affect sites who place ads above-the-fold to a normal degree, but affects sites that go much further to load the top of the page with ads to an excessive degree or that make it hard to find the actual original content on the page. This new algorithmic improvement tends to impact sites where there is only a small amount of visible content above-the-fold or relevant content is persistently pushed down by large blocks of ads.

The algorithm analyzes adverts in fixed positions; the Pagerank for sites using pop-ups, pop-unders or overlays will not be affected.

Google estimates the change will impact 1% of searches, i.e. you could encounter result reordering for one in every 100 searches. If your site’s affected, they recommend testing it with the Browser Size tool.

Perplexing Prerequisites

As with most search algorithm changes, Google is holding all the cards and gives us little to go on…

1. What do Google consider to be an advert? They’re not always banners or third-party scripts?
2. What do Google consider “above-the-fold”? It’s a dubious design term which changes from device to device and has no authoritative specification.
3. How do Google know whether an advert is above the fold? It’s easy to reposition advert blocks with CSS or JavaScript which wouldn’t necessarily be noticed by the algorithm.
4. How do they rank pages which use responsive design and reposition or remove adverts according to the screen size?
5. Google AdWords recommends advert positions above the fold. You may have received messages stating that you’re losing revenue because you’re under-utilizing the maximum number of slots. Could you be penalized for using Google’s own advice?

It’s great Google want to improve the web and search is their core business — they can do what they like and we’re free to use them or not. That said, should a company as powerful as Google be able to dictate something as subjective as design or user experience?

The Apple and Microsoft websites are essentially huge multi-page adverts. Could those sites be downgraded because Google (a major competitor) considers them to offer a bad user experience?

And where could it end? Could Google consider downgrading predominantly red designs because it’s considered a danger color in some cultures? Are they impeding your creative freedom? Is it censorship?

Don’t Panic

The vast majority of site owners need not be alarmed. Google’s announcement sounds more like marketing spin than an advanced new technology which will change the way designers approach pages.

I suspect the algorithm loads each page in a browser engine which emulates a 1024px width screen. CSS and JavaScript effects parsed during the initial page load may be applied but event or timer-driven code wouldn’t run. It then works out the vertical position of the first major content block and if it’s more than, say, 600px down, the Pagerank would be reduced accordingly. The overall impact is likely to be tiny, though. Factors such as keyword relevancy and even page weight will have a bigger effect.

There’s an easy way for site owners to avoid downgrades: simply place all your adverts at the bottom of the page then rearrange the content using CSS3 animations or JavaScript events. I’m no fan of intrusive advertising but that’s a horrible user experience — far worse than a little scrolling. Unfortunately, Google won’t know unless they manually check the site.

Will Google’s new algorithm affect your site? Is the policy at odds with Google’s advertising business? Is Google using it’s power to dictate website design and code quality?

Let’s start by defining the word “function.” A function is a self-contained piece of code which carries out a particular task (or function!). A key benefit of using functions is that they are reusable; if you have a task that needs to be performed a number of times, a function is an ideal solution. They can be either defined by you or by PHP (PHP has a rich collection of built-in functions). This article will focus on programmer-defined functions but will touch briefly on PHP’s functions to complete the picture

Read the original post:
PHPMaster: Defining and Using Functions in PHP

There reaches a point in every web developer’s life when they need a country selector — perhaps for a sign-up form or delivery address. So we find a list of all 249 countries, insert a select box into our HTML code and consider that a job well done.

It’s not.

Country select boxes are dreadful. The problems include:

1. Too many choices
Locating your country within 249 items is a usability nightmare.

2. An awkward interface
Select box controls differ between devices, OSs and browsers but one thing is certain — the user will need to scroll around to find their country. That often means switching from keyboard to mouse or lots of swiping on your mobile.

3. Sorting problems
If your site is primarily visited by US users, an alphabetic list displays “United Arab Emirates” and “United Kingdom” first. Some developers address this by putting the most likely countries at the top but this can confuse users expecting an alphabetically-ordered list.

4. No consideration for alternative country names
Country lists rarely consider alternative names. I live in the UK but any of United Kingdom, UK, Great Britain, GB, Britain or England could be defined by the developer.

5. Poor internalization
What if a Spanish user tries to locate “España” in your English list? At best, they’ll find Estonia. In addition, lists rarely consider international country codes such as ES or US.

6. No consideration for abbreviations or mis-keying
If a user enters a term such as “nited”, “States” or “America” it’s unlikely they’ll locate the USA.

Fortunately, Christian Holst from the Baymard Institute has developed a solution which solves the issues for us: see Redesigning the Country Selector.

It’s a jQuery plugin which replaces a standard HTML select box with an auto-complete control. The jQuery UI Autocomplete plugin is supplied but you can use your own implementation if necessary.

Several properties can be defined in the HTML:

<select name="Country" id="country-selector" autofocus="autofocus">
<option value="Austria" data-alternative-spellings="AT Österreich Osterreich Oesterreich ">Austria</option>
<option value="Spain" data-alternative-spellings="ES España">Spain</option>
<option value="United Arab Emirates" data-alternative-spellings="AE UAE Emirates">United Arab Emirates</option>
<option value="United Kingdom" data-priority="2" data-alternative-spellings="GB Great Britain England UK Wales Scotland">United Kingdom</option>
<option value="United States" data-priority="1" data-alternative-spellings="US USA United States of America">United States</option>
</select>

This snippet is identical to most country select code except:

• If a data-priority code is defined, it’s assumed to have a higher priority than countries without a code. The lower the priority number, the higher it will appear in the auto-complete list.
• A space-separated list of alternative codes and spellings can be defined in the data-alternative-spellings attribute.

To convert the select to an auto-complete box you simply need to call the jQuery plugin method:

$("#country-selector").selectToAutocomplete();

There are many more options so I suggest you try the demonstration and view the documentation at baymard.com/labs/country-selector. The open-source code is released under the MIT License and is available at GitHub.

The plugin is far superior to other implementations I’ve seen — including, ahem, my own. Note that it doesn’t work in IE6 or 7 but those browsers will still display the standard select box. It’s not limited to countries either and you can use any type of data. Recommended.

In part one of this mini series, we tackled the question of implementing a slider when you want to create a range of values, not just one. If you haven’t read part one, you’ll be feeling a little bit lost so I advise you go and check out iOS Range Slider: Part One . Still with us?

More:
BuildMobile: Wicked iOS Range Slider: Part Two

One of the commonly used iOS controls is the slider control. It’s a great, all purpose slider, that allows you to quickly swipe your finger along the screen to set a value. Things get a little complicated when you want to create a range of values however. The options are somewhat limited.

Read More:
BuildMobile: Wicked iOS Range Slider: Part One

With today’s snazzy and competitive “Web 2.0” and social media world, universal design is many times forgotten. It’s bewildering as to why since there are many social, technical, financial, and legal reasons which support universal design practices. Let’s discuss some of the more prevalent issues in websites today, and how they relate to the main universal design principles. The Principles First, let’s review the seven universal design principles including some web-related examples.

Link:
DesignFestival: Popular Mistakes in Universal Web Design

The role of search in your site can be a hot topic. Sometimes there is pressure to make it a giant bandage to cover poor navigational structure, and other times it’s included just because “every site needs search.” Let’s look at three pervasive myths about search and two questions that will help us create a strategy unique to every site. Misconceptions About Search Myth #1: Site Visitors Prefer to Find Information With Search Researchers have worked to combat this myth and have found that site visitors’ behavior does not naturally trend toward search first, even when searchers know exactly what they’re looking for.

See the original article here:
DesignFestival: Creating Meaningful Site Search by Challenging Assumptions

Next time you’re on a project where a designer is involved, it will help to keep these five tips in mind when it’s time to present wireframes:

1. Be visually minded

Your meeting will fall flat if the designer isn’t able to start creating mental visual concepts about how the design could start coming together. One way to help create the right atmosphere is to make attractive wireframes. If you are like me and aren’t a designer, then spend the extra effort to learn about basic design principles. This applies whether they are low or high fidelity, digital or hand-drawn.

Another way to serve these conceptual thinkers is to focus on the overall concepts of the site and how you see it coming to life. There couldn’t be a better place to employ digital or paper prototypes, if you are familiar with them, to help both of you visualize and discuss.

2. Channel creativity

Any quality designer will tell you that the best designs are produced within constraints. Creativity that is not channeled can be debilitating. One way to do this is to always talk openly about site goals, technical limitations, audience, budget, and timeline.

Designers are visionaries who are thinking in terms of design innovation and will likely keep creating new ideas during the whole design process. These are often great ideas that improve upon your work, but they can also frustrate the scope of the project. Clearly stating the limitations the design is working within can be a relief for everyone.

3. Focus on enjoyment

If designers’ jobs are merely to skin wireframes, their motivation will be lackluster, and who could blame them? Talk about where you see people being delighted, surprised, or specifically cared for by the site. Especially if you know the types of people that will be using your site, you can discuss how each personality would benefit individually from the interface experience. This will help them focus their energy, build excitement, and lead to innovative ideas for improvement.

4. Break it up

When you can, avoid dumping all of your documents and requirements on the designer at once. This will be overwhelming for both of you and can throw the creative process out of balance. You’ll probably end up needing one or two bigger meetings, but it will help if you can have some shorter meetings beforehand where you present sketches, talk about ideas, or talk through specific pages or challenges. When the bigger meetings roll around, you’ll have less groundwork to lay at the forefront and it will be easier to get momentum built. This process will make the transition to the design phase seamless.

5. Make it personal

It makes a world of difference to get to know the designers you’ll be working with personally. How do they best consume information? What role does emotion play in their decisions? What time of day is their mind most focused to absorb details versus think about the big picture? Do they need to marinate on something awhile to offer feedback or is it more instantaneous? Do they need coffee before your meetings? The more you can find out, the better you can personalize your projects with them to everyone’s benefit.

A Note for the One-person Shops

If you happen to be a one-person shop, where you are developing the strategy, planning/wireframing, designing, and coding all yourself, these still apply! As a multi-talented individual with a heavy task load, make sure to think about the different modes in which you are asking your brain to work. By helping yourself think conceptually, visualizing, using constraints, thinking about enjoyment, and breaking the work up into smaller segments, you will be all set for the design phase.

Ideas, even earth-shatteringly magnificent ones, that aren’t communicated effectively can suck the life right out of a project. For the next couple of weeks I am going to be discussing considerations for presenting your IA work to various audiences.

Here are four guidelines to keep in mind while you’re preparing to meet with or present IA directions to the developers involved in your next project:

Be respectful.

In every situation, always respect the developers. I’ve unfortunately been witness to and even participated in hasty critique of developers’ work. The truth is that we don’t know the constraints they were under when they created a system, what obstacles they had to overcome, and the problems that have already been solved. Make assumptions with benevolence, draw out current weak points as springboards for discussion, and use the project goals to guide constructive conversations.

Be brief.

Developers usually have several complicated problems rolling around in their heads that they’re in the middle of solving (occasionally this creates the illusion that they’re not listening, but don’t be fooled – they are). Acknowledge their cognitive load and don’t take up more time than is reasonable. They will respect you for your brevity and be glad to get back to working on those solutions.

Get to the good stuff.

These pragmatic problem solvers benefit from getting right to the meat of the matter, so make sure you cut verbal fluff where you can. Be careful here: that doesn’t mean they aren’t interested in the project goals, site audience, or other “soft” topics. In fact, it’s these details that give their work context and purpose. It’s the delivery which matters, which should be sans pretense and filler words.

Engage with the details.

From the very beginning of a project, the developers should and will be thinking through implementation details. Stay a step ahead by preparing thoughts and questions related to the implications for both front and back end development. Every piece of a wireframe or prototype impacts their scope. Sometimes this can get frustrating if you’re excitedly sharing a big idea and they’re giving you five reasons the execution of this idea is not going to fly. Expect this back and forth and be thankful that the development team is putting all that thought into the project.

Of course, I am painting with broad strokes here and every developer is unique (I work with ten and am married to one, so I have some firsthand experience). These guides are just a good place to start as you get to learn about and relate to these individuals on your project team.

In my last post, I mentioned that one way custom controls on a mobile device work well is if they mimic a real-world control. Let’s look at a turntable metaphor as an example: an app that looks like an old turntable might have a moveable needle, knobs to turn, and the ability to scratch (I found out that apps similar to this actually exist, but I’ve not checked them out).

This might be Apple’s favorite rule to break. To see what I mean, check out the calendar app on an iPad. It looks a lot like a traditional datebook with all of those flippable pages, but it’s the tiny arrows at the bottom that you have to tap to flip the page. There’s no option to use a swipe for page turning.

The iCal app doesn’t allow page turns by swipe

In an effort to do what they say and not what they have done above, let’s look at some ways that you can deliver a consistent experience that makes sense to the people who will be using your app:

• Get off the computer. In as many ways as possible, the abstraction should work as the subject itself. If you are building the turntable app that I mentioned earlier, then by all means get your hands on a turntable! Put a record on, adjust the knobs, listen to the crackle of the needle against vinyl, pay attention to the details that make it an enjoyable experience. Take notes.
• Improve on “real life.” The advantage of having a turntable or a datebook on a multi-touch digital device in the first place is that you can do all manner of things you can’t do on a real turntable or datebook. Increase enjoyment by improving upon the real world object where possible, both in appearance and technical ability.
  For example, being able to swipe to flip the page of an eBook is a fun interaction but becomes a chore if you are forced to do it. A digital turntable might have secondary controls that don’t require the users who are in a hurry to set the needle or pick a new album. Plan for advanced or frequent users of your app by creating alternate task flows that focus on efficiency.
• Try it before you build it. The more you can experience the app you’re making before it’s built, the more you gauge how well the metaphor is coming across and where the holes are. A cheap and effective way to do this is through paper (or even felt) prototypes, where you can “act out” the interactions with printouts or drawn mockups.
  So, in our turntable example, you could demonstrate that you want the needle arm to snap to the edge of the record when it’s tapped once, but dragging allows it to be placed anywhere. This activity is instantly collaborative since it’s not on someone’s personal computer and leads to lots of clarifications. Make sure to invite the developers; they will think in terms of execution and can bring technical opportunities and limitations to the discussion.
• Think through details. I like to think of developers as the directors that pull the working parts together into a cohesive unit, telling the “actors” where to go and when to make the story believable. It makes the process much smoother and takes the pressure off if these interactions have been discussed beforehand. That’s why it’s best to avoid the temptation to sweep even small areas of vagueness under the rug during the planning and design phases.
  It’s all too tempting to say, “the developer can flesh those details out, we don’t have time to worry about all those interactions right now.” Remember that your metaphor will be fail without detail-oriented production; it’s the direct manipulation and carefully planned responsiveness that makes the app feel “right.”

Chances are that you are building an app where more standard controls are optimal and there’s no need to make it look like something else. If you’re not sure, take into account who’ll be using your app, what purpose the metaphor would have, and the unique value the metaphor would bring to the people using your app. Don’t forget that enjoyment counts as value!

We are very excited to announce the arrival of our newest family member: Design Festival!

Design Festival is an exciting new website created from the ground up by the passionate team here at SitePoint. We want to explore web design topics in more detail, and decided a whole new website would provide the focus we’ve been searching for.

Design Festival will be the new home for web design professionals from around the world. We are exploring different web design techniques, with an emphasis on logo design, UX, and typography.

If you love web design, this site will provide an outlet for your passion. Please join us!

• Access best-practise UX design, logo design, typography, and coding advice.
• Indulge your passion for design – and learn a thing or two as you go.
• Contribute your own expertise to help others sharpen their skills.

Please visit the new site, join our Facebook page, and follow us on Twitter to stay updated on all the exciting Design Festival news. We’d love to hear all your feedback, so please let us know what you think.

If you’d like to become a contributor to this website by either writing a post or tutorial, please get in touch: editor@designfestival.com.

Thanks, as always, for your ongoing support of SitePoint and our sister sites. We appreciate it, and hope you love Design Festival as much as we do.

If you’ve been lucky enough to work on an iOS app for the iPhone, you’ve probably had two experiences:

1. Sweet freedom! There is no cross-browser compatibility to concern yourself with and a nearly limitless array of possible experiences you can build into your app.
2. Paralyzing freedom! Just like picking the right box in the cereal aisle, too many choices can leave you frustrated and resorting to whatever you’re most familiar with.

It is not difficult to create elegant, yet complex interactions on a website. Take web forms, for example; many fields and directions on one page can be smoothly navigated with design cues, easily scanned layout, and responsive controls. This is not the case in iOS, where a series of interactions on separate screens must work together to create one seamless experience.

As I’ve worked in the iOS platform, I’ve noticed how my web biases inform my iOS wireframes and task flows. Here are some ways I’ve learned to be aware of these biases and avoid them:

• Reset expectations about typing. Typing is so commonplace these days, we barely think about it. But no matter how speedy someone is on a mobile keyboard, it is always easier to select text on a touch device than it is to type it. Before you add a text field ask yourself: is this absolutely necessary? 

If it makes sense for your application, dynamically populate a list of possible answers below an input field once the user starts typing a letter or two (Google and Path are two of the many apps with this type of auto-complete functionality). Shave seconds off of interactions wherever you can because those seconds add up!
• Condense labels for forms and tables. Brevity is always advisable on the web, but it’s non-negotiable in iOS. Any time label text for table elements is wrapped or truncated, it interrupts the visual flow. Keep labels as short as possible without sacrificing meaning.
• Rethink forms. Instead of a consecutive list of questions and input fields on one long screen, think about forms on iOS as several quick interactions strung together. It’s helpful to maintain consistency with iOS standard controls by keeping cancel/back and submit/next buttons in the navigation bar at the top. The best forms are not drudgery to the user but just steps that must be taken to get something useful done.
• Take advantage of gestures, but… Gestures are tricky because they’re easy to both under and overuse.  There are three ways that I find gestures most appropriate:
  1. Offer them in the same way you might offer a keyboard shortcut in a desktop application — it’s there for improved experience and efficiency, but it’s not necessary to make the app function.
  2. Use them if you have created realistic controls that mimic real-world interactions.
  3. Present them in your app when you need to require deliberate intention (like answering your phone or deleting an account).
• Think in taps, not clicks. A finger tip is infinitely bigger than the tip of a mouse pointer, and that significantly affects your interface. Once you have a wireframe or mockup put together for a screen of your app, step back and look at it. Does it look like Honey I Shrunk the Web Page with lots of touchable areas crunched together? Is someone with thick fingertips going to be tempted to throw their phone across the room out of frustration? This seems obvious, but it is can be a daunting challenge to stop thinking in clicks.
• Don’t go overboard. It’s easy to swing too far in the other direction and use an array of different native elements because they’re there. The switch is an example of an element that has been widely overused because of its novelty. Well-placed interface elements put the people using your app in control, but superfluous interactions can make them feel like your marionette. A critical eye and some honest colleagues will help prevent interface bloat.

Instead of strictly following these guidelines, which will change as the platform changes, it’s best to focus on thinking critically about the medium and the people your product reaches. The advent of hundreds of millions of mobile touch devices is revolutionizing the way we think about the web and even desktop applications. Stay ahead of the curve by challenging your paradigms now!

Whether you’re testing an existing product, involved in a site redesign, or working on a completely new site, your biggest challenge is often yourself. Here are a few ways you might unintentionally cause problems:

• Your personal experience with a company, product, or application skews your interpretation. Think about an application you use daily. You know exactly where it frustrates you the most and maybe even how you’d fix it. Now imagine you were hired to make improvements to that app. You’d want to go straight to the source of your frustration. But if you limited your testing to just that area, you could miss a more global and crippling problem because of your tunnel vision.
• Years of experience using and working on the Web helps you to become an expert, but it also can create blind spots. Assumptions about how the Web should function based on what has worked and failed in the past can be indispensable, but also dangerous. When doing realistic illustrations, artists say, “draw what you see, not what you know,” and this is the same principle.
• Lots of pressure from higher-ups in a company to affirm their theories can implicitly affect the way you run tests and ask questions, especially if you’re new. There’s a reason people can be skeptical of tests funded by pharmaceutical companies. You may never skew results on purpose, but it’s easy to do unintentionally when the stakes are high enough!

Whether you’re conducting formal usability testing or just meeting with your team to discuss wireframes, your deeply held convictions can influence you anywhere! Here are some ways to actively work against your biases:

Avoid asking leading questions

Such questions hint at the answer you’re expecting to receive. For example, analyze how the statement below may be leading:

I would like you to use this form to complete your order. Your card won’t be charged when you click the submit button, so please finish the whole process.

The leading is subtle, but the statement assumes that the person using the site knows that you’re supposed to click a button at the end of a form, and that it’s called a submit button. Even more subtle is that just by saying the words “submit button,” you’ve now likely caused your participant to give more attention than normal to that element.

Be empathetic to participants

Your testing will be most successful if you recognize the strong desire many people have to do a task properly. Constant apologizing will likely make the test run too long, and can make for a stressed-out participant (making you feel awfully mean).

By paying careful attention to your tone, and writing an assuring and informative script to lead into sessions—as well as gently reminding participants during the session that you’re testing the web site or app, and not the individual—you’re more likely to create an environment that produces impartial results. If the participant simply struggles to figure out an interface you made and thought was quite clear, you’re at an especially high risk of becoming defensive, or asking leading questions to achieve an expected outcome.

Beware of your assumptions and bad memory

As soon as a test session is over, your brain starts to fit the new information into your existing assumptions about how things work, forgetting or altering those new pesky details.  The steps your brain takes to remain efficient do not always lead to the most accurate synthesis of information—especially if lots of time has passed between project stages. It’s impossible to remember everything that happened during the test accurately, even if you are a good note-taker (although, notes help!). Consider recording the screen and audio during sessions at least, so that you can refer back during analysis.

There’s no need to stress too much over these things, but do learn to be wary of your inclinations over time. Your best tests and internal discussions will happen as you learn to remove your biases from them.