User experience remastered pdf

These considerations will inform and constrain your functional possibilities. By imagining the process our users might go through, we can come up with potential requirements to help meet their needs. We can also look to our competitors for inspiration. Anyone else in the same business is almost certainly trying to meet the same user needs and is probably trying to accomplish similar product objec- tives as well.

Has a competitor found a particularly effective feature to meet one of these strategic objectives? How have they addressed the same trade-offs and compromises we face? Some gaming platforms, for example, offer users the ability to create social groups of fellow players. Adopting or building on their approach when scoping a similar feature for our digital video recorder may give us an advan- tage over our direct competition.

Programmers often hate specs because they tend to be terribly dull, and the time spent reading them is time taken away from producing code. As a result, specs go unread, which in turn reinforces the impression that producing them is a waste of time—because it is!

Things change during implementation. This, however, is not a reason to abandon writing specs as a lost cause. Instead, it highlights the importance of specs that actually work.

When things change during implementation, the answer is not to throw up your hands and declare the futility of writing specs. Writing It Down No matter how large or complex the project may be, a few general rules apply to writing any kind of requirements. Be positive. For example, instead of this: The system will not allow the user to purchase a kite without kite string. This would be better: The system will direct the user to the kite string page if the user tries to buy a kite without string.

Compare these examples: 1. The most popular videos will be highlighted. Videos with the most views in the last week will appear at the top of the list. What counts as popular? Videos with the most comments? And what constitutes highlighting them? By removing the possibility of differing interpretations, the second requirement neatly skirts the kinds of arguments likely to crop up during or after implementation. Avoid subjective language. So perhaps this require- ment would be best of all: The look of the site will conform to the company branding guidelines document.

The whole concept of hipness has now disappeared entirely from the requirement. Instead, we have a clear, unambiguous reference to established guidelines. But images, audio, and video can be more important than the accompanying text. Identifying all the content types associated with a feature can help you determine what resources will be needed to produce the content or whether it can be produced at all.

The real value of an FAQ to users is that it provides ready access to commonly needed information. We only have to collect the essential information needed to design an appro- priate vehicle for that content. Once it has been validated against our strategic objectives, any content feature inevitably sounds like a really good idea—as long as someone else is responsible for creating and maintaining it. You might be able to hire on contract resources or, more likely, stick someone down in marketing with the job to create the content in time for the initial launch, but who will keep it up to date?

Content—well, effective content, anyway— requires constant maintenance. Approaching content as if you can post it and forget it leads to a site that, over time, does an increas- ingly poor job of meeting user needs. This is why, for every content feature, you should identify how frequently it will be updated. The frequency of updates should be derived from your strategic goals for the site: Based on your product objectives, how often do you want users to come back?

Based on the needs of your users, how often do they expect updated informa- tion? If your site has to serve multiple audiences with divergent needs, knowing which audience a piece of content is intended for can help you make better decisions about how to present that content. Information intended for children requires a different approach from information intended for their parents; information for both of them needs yet a third approach. For projects that involve working with a lot of existing content, much of the information that will feed your requirements is recorded in a content inventory.

Taking an inventory of all the content on your existing site may seem like a tedious process—and it usually is. But having the inventory which usually takes the form of a simple, albeit very large, spreadsheet is important for the same reason that having concrete requirements is important: so everyone on the team knows exactly what they have to work with in creating the user experience.

Prioritizing Requirements Collecting ideas for possible requirements is not hard. Almost everyone who regularly comes in contact with a product—whether they are inside the organization or outside—will have at least one idea for a feature that could be added.

The tricky part is sorting out what features should be included in the scope for your project. In other cases, one requirement can serve multiple strategic objectives right. Some- times one requirement can be applied toward multiple strategic objectives. Similarly, one objective will often be associated with several different requirements. In the case of time constraints, you can push features out to a later release or project milestone.

For resource constraints, technological or organizational changes can sometimes—but, importantly, not always—reduce the resource burden, enabling a feature to be imple- mented. However, impossible things will remain impossible. Few features exist in a vacuum. Even content features on a Web site rely on the features around them to inform the user on how best to use the content provided.

Some features will require trade-offs with others in order to produce a coherent, consistent whole. Is it preferable to go with a multiple-step process, or should you rework the database system? It depends on your strategic objectives. In these cases, whether features end up in the project scope all too often comes down to corporate politics. When stakeholders talk about strategy, they usually start out with feature ideas, and then have to be coaxed back to the underlying strategic factors.

Because stakeholders often have trouble separating features from strategy, certain features will often have champions. Focus on strategic goals, not proposed means of accomplishing them.

Admittedly, this is often easier said than done. This is the next level up from scope: developing a conceptual structure for the site. Interaction design concerns the options involved in performing and completing tasks. Information architecture deals with the options involved in conveying information to a user. By building this understanding into the structure of our product, we help ensure a successful experience for those who use it.

Any time a person uses a product, a sort of dance goes on between the two of them. The user moves around, and the system responds. Then the user moves in response to the system, and so the dance goes on.

The system could just do its thing, and if some toes got stepped on, well, that was part of the learning process. But every dancer will tell you that for the dance to really work, each participant must anticipate the moves of the other. Programmers have traditionally focused on and cared most about two aspects of software: what it does and how it does it. Especially back when computing power was a limited resource, the best approach was the one that got the job done within those technical limitations.

The approach that works best for the technology is almost never the approach that works best for the person using it. Thus, software acquired the reputation that has haunted it for most of its existence: Software is complicated, confusing, and hard to use.

The new discipline that arose to help software developers do this is called interaction design. For example, does the system treat a particular feature as a thing the user consumes, a place the user visits, or an object the user acquires? Different sites take different approaches. Knowing your conceptual model allows you to make consistent design decisions. For example, the conceptual model for the shopping cart compo- nent of a typical e-commerce site is that of a container.

Suppose the conceptual model for the component were a differ- ent real-world analog, such as a catalog order form.

The system might provide an edit function that would replace both the add and remove functions of the traditional cart, and instead of using a checkout metaphor to complete the process, users might send their orders in. Which to choose? Using conceptual models people are already familiar with makes it easier for them to adapt to an unfamiliar site.

Unfamiliar conceptual models are only effective when users can correctly understand and interpret them. A conceptual model can refer to just one component of a system or to the system as a whole. Understanding the models users themselves bring to the site Does it work like a retail store?

Does it work like a catalog? The home page of the site for Southwest Airlines used to consist solely of a picture of a customer service desk, with a stack of brochures to one side, a telephone to the other side, and so on. Southwest must have gotten tired of being used as a bad example; its site subsequently became light on metaphor and con- siderably more functional. The old Southwest Airlines site is a classic example of conceptual models being tied too closely to real-world counterparts.

A good example of this type of defense can be seen in any car with an automatic transmission. Bad for the car, bad for the driver, and possibly bad for an innocent bystander who happens to be in the path of the lurching car. But even with such measures in place, some errors are bound to happen.

But be careful— some of the most irritating behavior of software products results from well-intentioned efforts to correct user errors. In these cases, the system should provide a way for users to recover from the error. The best-known example of this is the famous undo function, but error recovery can take many different forms.

Of course, this warning is only effective when users actu- ally notice it. For as long as people have had information to convey, they have had to make choices about how they structure that information so other people can understand and use it. Because information architecture is concerned with how people cognitively process information, information architecture consid- erations come up in any product that requires users to make sense of the information presented.

Most commonly, information architecture problems require creat- ing categorization schemes that will correspond to our own objec- tives for the site, the user needs we intend to meet, and the content that will be incorporated in the site.

We can tackle creating such a categorization scheme in two ways: from the top down, or from the bottom up. A top-down approach to information architecture involves cre- ating the architecture directly from an understanding of strategy plane considerations: product objectives and user needs. Starting with the broadest categories of possible content and functionality needed to accomplish these strategic goals, we then break the cat- egories down into logical subsections.

This hierarchy of categories and subcategories serves as the empty shell into which the content and functionality will be slotted.

A top-down architectural approach is driven by considerations from the strategy plane. Approaching the archi- tecture from the top down can sometimes cause important details about the content itself to be overlooked. The categories just have to be the right ones for your users and their needs. Some people favor counting the number of steps it takes to complete a task or the number of clicks it takes for a user to reach a particular destination as a way to evaluate the quality of a site structure.

The most important sign of quality, however, is not how many steps the process took, but whether each step made sense to the user and whether it followed naturally from the previous step. Web sites are living entities. They require constant care and feed- ing. Inevitably, they grow and change over time. One trait of an effective structure is its ability to accommodate growth and adapt to change. But the accumulation of new content will eventually require a re- examination of the organizing principles employed on the site.

The entire user experience, including the structure of the site, is built on an understanding of your objectives and the needs of your users. The need for such structural change rarely announces itself in advance, though; often, by the time you can tell that you need to rework the architecture, your users are already suffering.

Architectural Approaches The basic unit of information structures is the node. A node can correspond to any piece or group of information—it can be as small as a single number like the price of a product or as large as an entire library.

By dealing with nodes rather than with pages, docu- ments, or components, we can apply a common language and a common set of structural concepts to a diverse range of problems. The abstraction of nodes also allows us to explicitly set the level of detail we will be concerned with.

These nodes can be arranged in many different ways, but these structures really fall into just a few general classes. Child nodes represent narrower concepts within the broader category represented by the parent node. Not every node has children, but every node has a parent, leading all the way up to the parent node of the entire structure or the root of the tree, if you prefer. Because the concept of hierarchical relationships is well understood by users and because software tends to work in hierarchies anyway, this type of structure is far and away the most common.

Hierarchical structure. A matrix structure allows the user to move from node to node along two or more dimensions. For example, if some of your users really want to browse products by color, but others need to browse by size, a matrix can accommodate both groups. A matrix of more than three dimensions can cause problems, however, if you expect users to rely on it as their primary navigational tool.

Matrix structure. Nodes are connected together on a case-by-case basis, and the architecture has no strong concept of sections. Organic structures are good for exploring a set of topics whose relationship is unclear or evolving. Books, articles, audio, and video are all designed to be experienced in a sequential fashion.

Sequential structures on the Web are used most often for smaller-scale struc- tures such as individual articles or sections; large-scale sequential structures tend to be limited to applications in which the order of content presentation is essential to meeting user needs, such as in instructional material. Sequential structure. At its most basic level, the organizing principle is the criterion by which we determine which nodes are grouped together and which are kept separate.

Different organizing prin- ciples will be applied in different areas and at different levels of the site. Generally, the organizing principles you employ at the highest lev- els of your site are closely tied to the product objectives and user needs. For example, a site with news-oriented content will often have chronology as its most prominent organizing principle. Timeliness is the single most important factor for users who, after all, look to news sites for information on current events, not history as well as for the creators of the site who must emphasize the timeliness of their content in order to remain competitive.

In fact, it usually has more than one. For example, suppose our site contained a repository of informa- tion about cars. One possible organizing principle would arrange the information according to the weight of the car in question.

For a consumer information site, this is probably the wrong way to organize the information. Organizing the information according to make, model, or type of car would probably be more appropriate for this audience. On the other hand, if our users are professionals who deal on a daily basis with the business of shipping cars overseas, weight becomes a very important factor.

For these people, qualities like fuel economy and engine type are consider- ably less important, if they matter at all. But as the preceding example shows, using the wrong facets can be worse than using no facets at all. The strategy tells us what the users need, and the scope tells us what information will meet those needs. The tool we use to enforce that consistency is called a controlled vocabulary. This is another area in which user research is essential.

Talking to users and understanding how they commu- nicate is the most effective way to develop a system of nomenclature that will feel natural to them. Controlled vocabularies also help create consistency across all your content. A more sophisticated approach to controlling vocabulary is to cre- ate a thesaurus. Unlike a simple list of approved terms, a thesau- rus will also document alternative terms that are commonly used but not approved for use on the site.

With a thesaurus, you can map internal jargon, shorthand, slang terms, or acronyms to their approved counterparts. A thesaurus might also include other types of relationships among the terms, providing recommendations for broader, narrower, or related terms.

Documenting these relation- ships can give you a more complete picture of the entire range of concepts found in your content, which in turn can suggest addi- tional architectural approaches. Having a controlled vocabulary or thesaurus can be especially help- ful if you decide to build a system that includes metadata.

Some of the metadata for that article might include. The name of the author. The date the piece was posted. The type of piece for example, a case study or article. The name of the product. The type of product. If emergency services suddenly shows potential as a lucrative new market for the company to expand into, having this metadata will allow us to rapidly create a new section to meet the needs of these users with the content we already have.

Connecting your search engine with a thesaurus and providing metadata for your content can help make the engine smarter. The search engine can use the thesaurus to map a search for a disal- lowed term to a preferred term; then it can check the metadata for that preferred term. Instead of getting no results at all, the user gets highly targeted, relevant results—and maybe even some recom- mendations for other related subjects that might be of interest.

For proj- ects involving a lot of content in a hierarchical structure, simple text outlines can be an effective way to document the architecture. In some cases, tools like spreadsheets and databases will be pressed into service to help capture the nuances of a complex architecture.

But the major documentation tool for information architecture or interaction design is the diagram. In fact, in most cases that level of detail only serves to confuse and obscure the information the team really needs. Early in my career, I found myself having to express the same basic interaction structures over and over again from project to project. Over time, I started standardizing the way I illustrated my ideas in my site diagrams.

The system I created to diagram site structures is called the Visual Vocabulary. You can learn more about the Visual Vocabulary, see sample diagrams, and download tools for using it at my Web site: www. See www. Who ends up responsible for structure often depends on the culture of the orga- nization or the nature of the project.

For content-heavy sites or in organizations in which creating a presence on the Web was initially seen as a marketing activity, the responsibility for determining the structure of the site has resided within content development, editorial, or marketing com- munications groups. If the organization has historically been led by technical people or had a technology-oriented internal culture, responsibility for structure has commonly fallen to the technical project manager working on the Web site.

Sometimes this person goes by the job title interaction designer, but others prefer to be referred to as an information architect. Because information architecture and interaction design issues are often so closely related, user experience designer has become a more common title for someone with these skills.

Your organization might not have the volume of ongoing work to warrant hiring a full-time user experience designer as a permanent member of your staff. But if you have a steady stream of new content and functionality being added to your site, a user experience designer can help you manage that process in the way that will be most effective for meeting the needs of your users and for meeting your own strategic objectives.

Your site will have a structure whether or not you plan it out. The sites that are built according to a clear structural plan tend to be the ones that require less frequent overhauls, produce con- crete results for their owners, and satisfy the needs of their users. On the skeleton plane, we further refine Strategy that structure, identifying specific aspects of inter- face, navigation, and information design that will make the intangible structure concrete.

On the structure plane, we looked at the large-scale issues of architecture and interaction; on the skeleton plane, our concerns exist almost exclusively at the smaller scale of individual components and their relationships. But information products have a unique set of prob- lems all their own.

Navigation design is the specialized form of interface design tailored to presenting information spaces. Finally, crossing both sides, we have information design, the presentation of information for effective communication. The information architecture applied a structure to the content requirements we developed; the navigation design is the lens through which the user can see that structure, and is the means by which the user can move through it. Information design crosses the boundary between task-oriented functionality and information-oriented sys- tems because neither interface design nor navigation design can be fully successful without good information design to support them.

I used to have a car that invariably caused trouble when- ever any of my friends drove it. The controls on my car were different from the conventions they were used to. Telephones are another good example of the importance of conven- tion.

From time to time, manufacturers have experimented with deviations from the standard three-by-four layout for the buttons on a telephone, such as two rows of six buttons each, or three rows of four. Circular arrangements still pop up from time to time, but these are becoming ever more rare as the rotary-dial phones on which they are based fade into the mists of technological oblivion.

Because both standards use a three-by-four matrix, people can adapt to either with relative ease, though a single standard would really be the best solution of all. This is not to say that the answer to every interface problem is slavish adherence to convention. Making your interface consistent with others that your users are already familiar with is important, but even more important is making your interface consistent with itself.

If you have two features with the same conceptual model, they are likely to have similar interface requirements. Using the same conventions in both places allows a user who is familiar with one to adapt quickly to the other. Even where the conceptual models for features differ, ideas that apply across a variety of conceptual models should be treated similarly if not identically wherever they appear. Giving these a consistent treatment throughout lets users apply what they already know from having used other parts of the system, getting them to their goals faster and with fewer mistakes.

Metaphors for the features of your product are cute and fun, but they almost never work as well as it seems they should. In some cases, you might be inclined to pattern the interface design for a particular function after the interface of a real-world object. Most interfaces and navigational devices in the real world are the product of the constraints of the real world: physics, the properties of materials, and so on. Screen- based products such as Web sites and other software have few of the same constraints.

However, this kind of approach usually obscures the nature of the feature instead of revealing it. What does that little picture of a telephone mean? Will it allow me to make a phone call? Check my voice mail? Pay my phone bill? Of course, the content of your site should provide some degree of context to help users make better guesses about what features your metaphors are intended to represent.

But the more diverse the range of content and functionality you offer, the less reliable these guesses become—and at any rate, some part of your audience is always going to guess incorrectly. It would be better and simpler to eliminate that guesswork altogether. Using metaphors effectively is really just about reducing the mental effort required for users to get around and use the functionality of your product. Tasks will often stretch across several screens, each contain- ing a different set of interface elements for the user to contend with.

Which functions end up on which screens is a matter of interaction design down in the structure plane; how those functions are real- ized on the screen is the realm of interface design. Successful interfaces are those in which users immediately notice the important stuff. For people with a background in programming, this way of think- ing can require some adjustment. So programmers are trained to treat every case equally, whether it represents one user or one thousand.

A well-designed interface recognizes the courses of action users are most likely to take and makes those interface elements easiest to access and use. Interface designs can employ a variety of tricks to ease users along the way to their goals. Even better is a system that automatically remembers the options a user selected the last time they stopped by, but this sometimes requires more technical acrobatics than would appear necessary on the surface, and as a result is impractical for some development teams to imple- ment successfully.

Technology tools and frameworks have inherent technical con- straints that limit the interface options available to us. This is actu- ally both bad and good. But this situation is also good, because users who learn how to work with a fairly small set of standard controls can apply that knowledge across a wide range of products.

New technologies sometimes bring the need to re-examine existing conventions or come up with some new ones. User experience designers continue to seek out new conventions for technologies like gestural controls and touchscreen devices. Most of the standard controls we see across a wide range of screen-based products originated with desktop computer operating systems like Mac OS or Windows.

These operating systems offer a handful of standard interface elements: Checkboxes allow users to select options independently of one another. Radio buttons allow users to select one option from among a set of mutually exclusive options.

List boxes provide the same functionality as checkboxes, but they do so in a more compact space because list boxes scroll. As with dropdowns, this enables the list box to easily support a large num- ber of options.

Action buttons can do lots of different things. Typically, they tell the system to take all the other information the user has provided via other interface elements and do something—take action—with it. Con- sequently, these interfaces involve a lot more choices to be made during the design process, and they tend to be harder to get right.

Radio buttons easily display all the available options right , but they take more space in the Juggling all the different interface elements and choosing from interface. True, that dropdown will save you some space on the screen relative to a set of radio buttons, but it will also hide the available choices from the user. Having people type in the categories they want to search might put less load on the database, but it puts more load on the user; if there are only six to choose from anyway, maybe some checkboxes would be better.

Navigation Design Designing navigation for the Web seems like a simple business: Put links on every page that allow users to get around on the site.

If you scratch the surface, however, the complexities of navigation design become apparent. The navigation design of any site must accom- plish three simultaneous goals:. First, it must provide users with a means for getting from one point to another on the site.

Second, the navigation design must communicate the rela- tionship between the elements it contains. What do those links have to do with each other? Are some more important than others? What are the relevant differences between them? This com- munication is necessary for users to understand what choices are available to them. Third, the navigation design must communicate the relation- ship between its contents and the page the user is currently viewing.

Communicating this helps users understand which of the available choices might best support the task or goal they are pursuing. In a physical space, people can rely to some degree on an innate sense of direction to orient themselves. Of course, some people just seem to be perpetu- ally lost.

Without that knowledge, the best approach is to assume that users carry no knowledge with them from page to page. After all, if a public search engine such as Google indexes your site, any page could be an entry point to your site anyway. Several common types of navigation systems have sprung up in practice.

Global navigation. Global navigation provides access to the broad sweep of the entire site. We use the term persistent to refer to navigation elements that appear throughout a site; again, keep in mind that persistent elements are not necessarily global. Instead, global navigation brings together the key set of access points that users might need to get from one end of the site to the other. Anywhere you might want to go, you can get there eventually with global navigation.

Local navigation. Supplementary navigation. Supplementary navigation provides shortcuts to related content that might not be readily accessible through the global or local navi- gation. Contextual navigation sometimes called inline navigation is embedded in the content of the page itself. This type of navigation—for example, a hyperlink within the text of a page—is often underutilized or misutilized.

When they are reading the text is often the moment users decide they need an additional piece of information. Instead of forcing your users to scan the page for the right navigation element—or worse, sending them scurrying to the search engine—why not put the relevant link right there?

Reaching all the way back to the strategy plane, the better you understand your users and their needs, the more effectively you can deploy contextual navigation.

Part 2 focuses on idea generation processes, including brainstorming; sketching; persona development; and the use of prototypes to validate and extract assumptions and requirements that exist among the product team.

Part 3 presents core design principles and guidelines for website creation, along with tips and examples on how to apply these principles and guidelines. Part 4 on evaluation and analysis discusses the roles, procedures, and documents needed for an evaluation session; guidelines for planning and conducting a usability test; the analysis and interpretation of data from evaluation sessions; and user interface inspection using heuristic evaluation and other inspection methods.

What is Conception and Gestation for Personas? Chauncey Wilson Chauncey Wilson is a UX Architect with 40 years of experience in human factors, usability, and user experience design. The author has published several books and chapters on usability engineering, brainstorming, surveys, victimization, and inspection methods. He has worked in small and large firms, started teams, consulted for a large firm, and consulted as a lone consultant.

Finally, you'll understand how to prototype and use these patterns to create websites and apps. Whether you're a UX professional looking to master mobility or a designer looking to incorporate the best UX practices into your website, after reading this book, you'll be better equipped to maneuver this emerging specialty.

Addresses the gap between theoretical concepts and the practical application of mobile user experience design Illustrates concepts and examples through an abundance of diagrams, flows, and patterns Explains the differences in touch gestures, user interface elements, and usage patterns across the most common mobile platforms Includes real-world examples and case studies for this rapidly growing field Visit www.

Information technologies play a significant role in modern information-driven societies, making a comprehensive understanding of digital media a fundamental requisite to success. Cases on Usability Engineering: Design and Development of Digital Products provides readers with case studies and real-life examples on usability methods and techniques to test the design and development of digital products, such as web pages, video games, and mobile computer applications.

Students, lecturers, and academics concentrating in computer science can use these cases to investigate how and why usability can improve the design of digital technology, offering diverse technological solutions that many academics have largely failed to disseminate. It uses, complements, integrates and extends theories, methods and tools from other scientific disciplines like: strategic management, information technology, managerial accounting, operations management etc.

During this period the main focus themes of researchers and professionals in BPM were: business process modeling, business process analysis, activity based costing, business process simulation, performance measurement, workflow management, the link between information technology and BPM for process automation etc.

In this collection of papers we present a review of the work and the outcomes achieved in the classic BPM fields as well as a deeper insight on recent advances in BPM.

We present a review of business process modeling and analysis and we elaborate on issues like business process quality and process performance measurement as weel as their link to all other organizational aspects like human resources management, strategy, information technology being SOA, PI or ERP , other managerial systems, job descriptions etc. We also present recent advances to BPR tools with special focus on information technology, workflow, business process modeling and human resources management tools.

Other chapters elaborate on the aspect of business process and organizational costing and their relationship to business process analysis, organizational change and reorganization. In the final chapters we present some new approaches that use fuzzy cognitive maps and a recently developed software tool for scenario creation and simulation in strategic management, business process management, performance measurement and social networking.

The audience of this book is quite wide. The first chapters can be read by professionals, academics and students who want to get some basic insight into the BPM field whereas the remaining present more elaborate and state of the art concepts methodologies and tools for an audience of a more advanced level. As technology and technological advancements become a more prevalent and essential aspect of daily and business life, educational institutions must keep pace in order to maintain relevance and retain their ability to adequately prepare students for their lives beyond education.

Such institutions and their leaders are seeking relevant strategies for the implementation and effective use of new and upcoming technologies and leadership strategies to best serve students and educators within educational settings.

As traditional education methods become more outdated, strategies to supplement and bolster them through technology and effective management become essential to the success of institutions and programs.

The Handbook of Research on Modern Educational Technologies, Applications, and Management is an all-encompassing two-volume scholarly reference comprised of 58 original and previously unpublished research articles that provide cutting-edge, multidisciplinary research and expert insights on advancing technologies used in educational settings as well as current strategies for administrative and leadership roles in education.

Covering a wide range of topics including but not limited to community engagement, educational games, data management, and mobile learning, this publication provides insights into technological advancements with educational applications and examines forthcoming implementation strategies.

These strategies are ideal for teachers, instructional designers, curriculum developers, educational software developers, and information technology specialists looking to promote effective learning in the classroom through cutting-edge learning technologies, new learning theories, and successful leadership tactics.

Administrators, educational leaders, educational policymakers, and other education professionals will also benefit from this publication by utilizing the extensive research on managing educational institutions and providing valuable training and professional development initiatives as well as implementing the latest administrative technologies. Additionally, academicians, researchers, and students in areas that include but are not limited to educational technology, academic leadership, mentorship, learning environments, and educational support systems will benefit from the extensive research compiled within this publication.

The SharePoint user experience is critical in application architecture and user acceptance. Using tools available to all developers, Building the SharePoint User Experience will show you how to rebuild a SharePoint site, taking it all the way from the default out—of—the—box experience to your very own customized user experience. Along the way you will receive a solid understanding of the SharePoint architecture that will enable you to take full advantage of the capabilities of SharePoint as a platform.

This will allow you to tailor the SharePoint user experience to increase the value of solutions and to work more effectively with projects. And that, of course, leads to successful SharePoint solutions in your business that your users are happy to accept and use. Value Management is a philosophy, set of principles and a structured management methodology for improving organisational decision-making and value-for-money.

The second edition builds on the success of the first edition by extending the integrated value philosophy, methodology and tool kit to describe the application of Value Management to the areas of service delivery, asset management, and, Programmes, in addition to Projects, products and processes. Value Management is a well-established methodology in the international construction industry, and in the UK has been endorsed as good practice in a range of government sponsored reports.

In this book the authors have addressed the practical opportunities and difficulties of Value Management by synthesising the background, international developments, benchmarking and their own extensive consultancy and action research experience in Value Management to provide a comprehensive package of theory and practice.

The second edition retains the structure of the first edition, covering methods and practices, frameworks of value and the future of value management. It has been thoroughly updated, and a number of new chapters added to encapsulate further extensions to current theory and practice.

Research in Value Management undertaken since publication of the first edition. Changes in Value Management practice particularly in Programmes and Projects. Developments in the theory of value, principally value for money measures, whole life value option appraisal, and benefits realisation.

An Appendix includes an extensive set of tools and techniques of use in Value Management practice. Construction clients, including those in both the public and private sectors, and professionals such as construction cost consultants, quantity surveyors, architects, asset managers, construction engineers, and construction managers will all find Value Management of Construction Projects to be essential reading.

It will also be of interest to researchers and students on construction related courses in Higher Education — particularly those at final year undergraduate and at Masters level.