Swapnil V. Patil patilswapnilv

## The_Book-_1__3.txt
 paradigm is the importance of emotional impact derived from design-the pure
 joy of use, fun, and aesthetics felt in the user experience.
  To put the paradigms in perspective, consider the concept of a new car design. In the first paradigm, the engineering view, a car is built on a frame that holds all the parts. The question of its utility is about how it all fits together and whether it makes sense as a machine for transportation. It is also about performance, horsepower, handling, and fuel mileage. The second paradigm will see the car design as an opportunity to develop ergonomic seating and maybe new steering control concepts, as well as placement of controls to react quickly to emergency driving situations.
  The design-thinking view of the third paradigm will also encompass many of the things necessary to produce a car that works, but will emphasize emotional


impact, "coolness" of the ride, and how to optimize the design to best appeal to the joy of driving and feelings of ownership pride. The des

## The_Book-_1__2.txt
4.1.1 You Are Here
We begin each process chapter with a "you are here" picture of the chapter topic in the context of the Wheel lifecycle template; see Figure 4-1. We have talked about eliciting work activity data (Chapter 3) and now we will analyze that data to understand the work context for the new system you are about to design.
  Our source for much of this material on contextual analysis comes from Beyer and Holtzblatt (1998). The credit for this is theirs; any errors of commission or omission are ours.
  Although the activities we describe for contextual inquiry and contextual analysis do occur somewhat in sequence, the sequence is not followed slavishly, allowing for reviewing or redoing a stage and, of course, for iteration.


## The_Book-_1__1.txt


This book is destined to become a primary reference for just about anyone involved in the development of interactive products of almost any kind. It addresses both the design process and design principles and goes beyond traditional usability to address all aspects of the user experience. The authors have distilled two careers' worth of research, practice and teaching into a concise, practical and comprehensive guide for anyone involved in designing for the user experience of interactive products.-Deborah J. Mayhew, Deborah J. Mayhew & Associates

## The_Book-_1__8.txt
Goal: Get a little practice in creating a flow model for an enterprise.
Activities:
� Follow up on your flow model initial sketch that you did in Exercise 4-1.
� Again represent each work role or system entity as a node in the diagram.


� Use arcs between nodes to show all communication and coordination necessary to do the work of the enterprise.
� Use arcs to represent all information flow and flow of physical artifacts.

## The_Book-_1__7.txt

Help the user by automating where there is an obvious need

  This section is about automation issues, but not all about avoiding automation. In some cases, automation can be helpful. The following example is about one such case.

Example: Sorry, off route; you lose!

  No matter how good your GPS system is, as a human driver you can still make mistakes and drive off course, deviating from the route planned by the system. The Garmin GPS units are very good at helping the driver recover and get back on route. It recalculates the route from the current position immediately and automatically, without missing a beat. Recovery is so smooth and easy that it hardly seems like an error.
  Before this kind of GPS, in the early days of GPS map systems for travel navigation, there was another system developed by Microsoft, called Streets and Trips. It used a GPS receiver antenna plugged into a USB port in a laptop. The unit had one extremely bad trait. When the driver got off track, the screen displayed the error messa

## The_Book-_1__6.txt
Let us revisit the example of a thermostat on a furnace from Chapter 8.
 Suppose that a user is feeling chilly while sitting at home. The user formulates a
 simple goal, expressed in the language of the work domain (in this case the daily
 living domain), "to feel warmer." To meet this goal, something must happen in the physical system domain. The ignition function and air blower, for example, of the furnace must be activated. To achieve this outcome in the physical domain, the
 user must translate the work domain goal into an action sequence in the physical
 (system) domain, namely to set the thermostat to the desired temperature.
   The gulf of execution lies between the user knowing the effect that is desired and what to do to the system to make it happen. In this example, there is a cognitive
disconnect for the user in that the physical variables to be controlled
(burning fuel and blowing air) are not the ones the user cares about (being warm). The gulf of execution can be bridged from either directio

## TheBook-_1__5.txt
will peak with many more participants than three to five.

You have to settle for a sensible approach with a practical outcome
Okay, so what is the answer? What is the best number of participants to use in testing? Our friend Jim Foley's answer to any HCI question was never
more appropriate than it is here: It depends! It takes as many participants as it takes for your situation, your application, your design, your resources, and your goals.


  You have to decide for yourself every time you do UX testing-how many participants can you afford. You cannot compute and graph all the curves we have been talking about because you will never know how many UX problems exist in the design so you will never know what percentage of the existing problems you have found. You do not have to use those curves, anyway, to have a pretty good intuitive feeling for whether you are still detecting useful new problems with each new participant. Look at the results from each participant and each iteration and ask if those results

## TheBook-_1__4.txt
 functions that are included are evolved in enough detail to support realistic user
 experience evaluation. Often the functionality of a vertical prototype can include a stub for or an actual working back-end database.
 A vertical prototype is ideal for times when you need to represent completely
 the details of an isolated part of an individual interaction workflow in order to
 understand how those details play out in actual usage. For example, you may wish to study a new design for the checkout part of the workflow for an
e-commerce Website.  A vertical prototype would show that one task sequence
 and associated user actions, in depth.


11.2.2 "T" Prototypes

## work
https://codepen.io/patilswapnilv/pen/vYBJYVV
https://codepen.io/patilswapnilv/pen/oNNzRMx
https://codepen.io/patilswapnilv/pen/XqLgyY


https://github.com/patilswapnilv/login-and-logout-redirect
https://github.com/patilswapnilv/Gravity-Pre-submission-Confirmation

## google-apps-script.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                patilswapnilv
                / google-apps-script.md
            
            
              Created
              June 26, 2019 06:01
                — forked from labnol/google-apps-script.md
            
              
                How to Learn Google Apps Script - The best resources for learning Google Apps Script, the glue that connects GSuite services including Gmail, Google Drive, Calendar, Maps, Analytics and more.
              
          
    Learning Google Apps Script

The best place to learn more about Google Script is the official documentation available at developers.google.com. Here are other places that will help you get up to speed.

Google Apps Scripts - Snippets by +Amit Agarwal
Apps Script Starter - Create Google Apps Script projects locally inside VS Code.
Digital Inspiration by +Amit Agarwal - Google Addons
Awesome Google Scripts  by +Amit Agarwal
Build with Google Apps Script - Setup a local development environment for Apps Script
Apps Script Webinars - YouTube - by +Eric Koleda
	paradigm is the importance of emotional impact derived from design-the pure
	joy of use, fun, and aesthetics felt in the user experience.
	To put the paradigms in perspective, consider the concept of a new car design. In the first paradigm, the engineering view, a car is built on a frame that holds all the parts. The question of its utility is about how it all fits together and whether it makes sense as a machine for transportation. It is also about performance, horsepower, handling, and fuel mileage. The second paradigm will see the car design as an opportunity to develop ergonomic seating and maybe new steering control concepts, as well as placement of controls to react quickly to emergency driving situations.
	The design-thinking view of the third paradigm will also encompass many of the things necessary to produce a car that works, but will emphasize emotional



	impact, "coolness" of the ride, and how to optimize the design to best appeal to the joy of driving and feelings of ownership pride. The des
	4.1.1 You Are Here
	We begin each process chapter with a "you are here" picture of the chapter topic in the context of the Wheel lifecycle template; see Figure 4-1. We have talked about eliciting work activity data (Chapter 3) and now we will analyze that data to understand the work context for the new system you are about to design.
	Our source for much of this material on contextual analysis comes from Beyer and Holtzblatt (1998). The credit for this is theirs; any errors of commission or omission are ours.
	Although the activities we describe for contextual inquiry and contextual analysis do occur somewhat in sequence, the sequence is not followed slavishly, allowing for reviewing or redoing a stage and, of course, for iteration.









	This book is destined to become a primary reference for just about anyone involved in the development of interactive products of almost any kind. It addresses both the design process and design principles and goes beyond traditional usability to address all aspects of the user experience. The authors have distilled two careers' worth of research, practice and teaching into a concise, practical and comprehensive guide for anyone involved in designing for the user experience of interactive products.-Deborah J. Mayhew, Deborah J. Mayhew & Associates
	Goal: Get a little practice in creating a flow model for an enterprise.
	Activities:
	� Follow up on your flow model initial sketch that you did in Exercise 4-1.
	� Again represent each work role or system entity as a node in the diagram.




	� Use arcs between nodes to show all communication and coordination necessary to do the work of the enterprise.
	� Use arcs to represent all information flow and flow of physical artifacts.

	Help the user by automating where there is an obvious need

	This section is about automation issues, but not all about avoiding automation. In some cases, automation can be helpful. The following example is about one such case.

	Example: Sorry, off route; you lose!

	No matter how good your GPS system is, as a human driver you can still make mistakes and drive off course, deviating from the route planned by the system. The Garmin GPS units are very good at helping the driver recover and get back on route. It recalculates the route from the current position immediately and automatically, without missing a beat. Recovery is so smooth and easy that it hardly seems like an error.
	Before this kind of GPS, in the early days of GPS map systems for travel navigation, there was another system developed by Microsoft, called Streets and Trips. It used a GPS receiver antenna plugged into a USB port in a laptop. The unit had one extremely bad trait. When the driver got off track, the screen displayed the error messa
	Let us revisit the example of a thermostat on a furnace from Chapter 8.
	Suppose that a user is feeling chilly while sitting at home. The user formulates a
	simple goal, expressed in the language of the work domain (in this case the daily
	living domain), "to feel warmer." To meet this goal, something must happen in the physical system domain. The ignition function and air blower, for example, of the furnace must be activated. To achieve this outcome in the physical domain, the
	user must translate the work domain goal into an action sequence in the physical
	(system) domain, namely to set the thermostat to the desired temperature.
	The gulf of execution lies between the user knowing the effect that is desired and what to do to the system to make it happen. In this example, there is a cognitive
	disconnect for the user in that the physical variables to be controlled
	(burning fuel and blowing air) are not the ones the user cares about (being warm). The gulf of execution can be bridged from either directio
	will peak with many more participants than three to five.

	You have to settle for a sensible approach with a practical outcome
	Okay, so what is the answer? What is the best number of participants to use in testing? Our friend Jim Foley's answer to any HCI question was never
	more appropriate than it is here: It depends! It takes as many participants as it takes for your situation, your application, your design, your resources, and your goals.



	You have to decide for yourself every time you do UX testing-how many participants can you afford. You cannot compute and graph all the curves we have been talking about because you will never know how many UX problems exist in the design so you will never know what percentage of the existing problems you have found. You do not have to use those curves, anyway, to have a pretty good intuitive feeling for whether you are still detecting useful new problems with each new participant. Look at the results from each participant and each iteration and ask if those results
	functions that are included are evolved in enough detail to support realistic user
	experience evaluation. Often the functionality of a vertical prototype can include a stub for or an actual working back-end database.
	A vertical prototype is ideal for times when you need to represent completely
	the details of an isolated part of an individual interaction workflow in order to
	understand how those details play out in actual usage. For example, you may wish to study a new design for the checkout part of the workflow for an
	e-commerce Website. A vertical prototype would show that one task sequence
	and associated user actions, in depth.


	11.2.2 "T" Prototypes
	https://codepen.io/patilswapnilv/pen/vYBJYVV
	https://codepen.io/patilswapnilv/pen/oNNzRMx
	https://codepen.io/patilswapnilv/pen/XqLgyY


	https://github.com/patilswapnilv/login-and-logout-redirect
	https://github.com/patilswapnilv/Gravity-Pre-submission-Confirmation