These demos represent aspects of the functionality and form of the design/education tool that we are creating. Notes below the links document the progress of development and implementation - including some "wrong paths"!
Highlighted text denotes the more functional and/or interesting examples.
If there has been an update to a previously viewed movie, you may need to delete downloaded Internet files to see the change (Tools/Internet Options/Delete Files in IE).
The current design shape with the earlier text description output for internal verification. I'm adding some of the additional configuration checks, along with the spacing checks.
Current checks include oven-fridge/cooktop pair check, tall appliances on island check, sink dishwasher check, adjacent mins/maxs, corner mins/maxs.
Coming soon - small/tall appliance check, tall appliances on open counter check, adjacent sinks check, fridge near entrance check... other?
First pass at merging the primary tool with some of the evaluation tools, though it won't be immediately apparent by looking at this version (updates coming soon!).
Note rule application options.
Added 4 options on the right-side pane : view, usage tests, familiar metrics, and activity descriptions... more to come.
Custom scroll bar for use in "windows" of interface. Example of use, vertical and horizontal.
May need to rethink colors and style of handle, buttons, but at least it is functional!
Update to last version. Includes being able to select from predefined kitchen and bathroom choices. Might be helpful to be able to flip bathroom or kitchen...See below for other improvement possibilities.
Based on Jarmo's base plan and partition components, simple example of customization at the apartment level. You can drag partitions from the "partition palette" and arrange them in the open area of the apartment to divide up the space. The flip button allows you to mirror the partition for the appropriate orientation.
Many extension possibilities here. Jarmo has mentioned being able to select from a few predefined choices for the kitchen and bathroom. Evaluation, either in the form of critics or evaluative tools, seems critical. Output should be fairly straightforward - a print out of the plan with partitions, plus maybe a list of partitions used and their model number. Finally, we should be able to collect data about what people do and choose - perhaps also considering some initial questionnaire data to get a user profile that we can connect with design result.
Updated elevation view on change, rule application on appliance drop, option to try to "minimize" versus "preserve spacing."
Will modify this version to work with questions, evaluation tools
Experimentation with another type of vertical view - elevation. This view may be provided to aid users in evaluating adjacency relationships. For example, it is very difficult to understand what it means to have the dishwasher to the right of or the left of the sink in plan view, particularly if the counters are rotated (counters 2,3,4). However, by seeing a "snapshot" elevation view, one can quickly understand how 2 adjacent appliances are ordered.
Lots of room for improvement here, such as the inclusion of vertical universal design elements such as knockouts, drawer/door facing for counters, wall markers, breakfast bar view, back wall versus "space" distinction, appropriately positioned cupboards, and placement of a see-through figure to understand dimensions.
Also includes the new appliance model (rather than resizing) approach.
Rather than distorting each appliance to match the dimensions dictated according to family size, I decided to create 5 (or fewer) models for each appliance that conformed to the relevant dimensions in a more appropriate way. So the smallest sink only has one bowl, while the largest has 3, etc. Although these do not necessarily represent actual product choices, they do represent reasonable dimensions, as identified by Xiaoyi.
I expect that it will look more reasonable to have the "economy" size appliances for a family of 1 or 2 in the sized plan, than the "default" luxury sizes we have been using. In future demos involving the plan, these models will be used.
This interface just displays the different appliances for each family size category along with dimension information. I also worked a bit on the simple animation routines for the fridge, oven, and dishwasher.
Next, I continue to investigate the feasibility of elevation view (in addition to cross-section view), with appropriate appliance and counter sizings.
Move the human-view marker around the plan view. On drop, the appropriate cross-section view, of appliance or counter, will display in the yellow rectangle.
Need to begin thinking about vertical elements, such as cabinets, that may or may not be present at a given location and adjust cross-section view accordingly - for example, there will not typically be cabinets over the island.
The cross-section view should be good for illustrating height-based principles, which are central to universal design. This view, however, may not help the user understand the implications of plan positioning - would a restricted elevation view be helpful and if so, would it be feasible?
Based on a diagram that Xiaoyi provided, dymanically shows the working area required by a single cook. One arm is bent and represents small local movements. The other arm is extended and represents reach movements.
Xiaoyi's human motion examples.
Select one of the initial designs and then transform it by growing and shrinking counters, adding or removing the island, and adding or removing the bar.
There is also a "trash" area for unneeded appliances, particularly the prep sink, which is placed on the shape only if the comfort is B or C _and_ the family size is 5+.
Resize tabs have been restyled in an attempt to better convey their purpose - am still not sure whether it will be apparent though.
I am a somewhat unsure on some of the transformations, both in terms of merging/reassining islands and bar and in shifting some of the appliances. Some of it may not matter if we accept that the design may not be optimal, but the user will discover that on evaluation - for example, it is easy for the sink and dishwasher to be separated, either by a long counter distance (sink on 4, dishwasher on 3) or on parallel counters (sink on 1, dishwasher on 4). I've also made the assumption that there shouldn't be both an island and counter 3 - so adding an island to G changes the shape to U, growing a U with an island to G removes the island.
I need to think more about the room object when the room is "closed" - the room should resize as appropriate when a breakfast bar is added (or a bar should not be allowed) and there should be a door at the entry. Windows?
Note that the application is now 100Kb+. There initially was an error on initial load, but I believe I have corrected it. It doesn't seem unreasonably slow at home (I connect at about 48.8), but I'm wary of how the size may grow as additional code for the evaluation tools are added. Maybe some "on demand" loading of tools and possibly some movement of code to server-side scripts (checking functions?) may help. Otherwise, we'll need an explanation of the several minute initial load-time required.
Increase/decrease width/depth of shape and island using pull tabs. Drag island to position within shape area.
Can continue to check rules, apply positioning.
In addition to providing a print out of sizing/postioning/placement actions for the initial design state, when you click to "check current dimensions," you get the current spacing in the dimensions text area and the results of two rule tests - adjacency and corners - in the actions text area.
Note that the corner rule frequently fails on the "within maximum test," even for the initial "good designs" - this is due to the fact that the counters often have to be resized when there is an island, due to a parallel rule, etc. This rule may be too difficult to maintain in practice.
I also made some corrections to other parts of the code. One question that came up - for the last edge placement on counter 2, when counter 3 is present with a space open for the entry, should it be just the depth of counter 3? Should it be the depth + the spacing for the open counter?
Notes on reasons for Xiaoyi's rules and how I may evaluate the design to determine rule adherence. Graphic representation of Xiaoyi's guided transformation rules for adding an island.
Modified get design php script to return a "closed" value based on whether the room should be closed off or open to adjoining space. Also made some corrections to generate rules script to insure that appropriate values were being referenced for different family sizes.
Room object added and now application of counter edge spacing and island positioning rules reflect whether the relevant wall is present. For the counter spacing, when an adjoining counter is absent, either wall-edge or open-edge rules apply. For island positioning, when an opposing counter is abset, either wall-island or open-island rules apply. Open-island rules were originally going to allow for a clearance of 0, but on visual inspection, Xiaoyi updated the rule to include space for the addition of a breakfast bar (or stools).
If the design includes a breakfast bar, it is added to the 3rd counter, if visible, else it is added to the island. It sizes to match the width of the counter. Some thought may need to be given for the addition of a second bar, to create an L-breakfast configuration, either on counters 3 and 4 or on island counters 3 and 4. None of the current start-states include an L-bar.
If a bar is attached to an island counter, appliances cannot be dragged onto that counter. Note, however, that if the appliances are already there, they remain there... should it be that you cannot place the bar on an island counter if there is an appliance there? How could this be added to the ondrag check?
The bar can also be added to any shape counter at this point, even if that counter abuts a wall. In order to change this, the inBounds of the shape counters will have to check for the presence of the appropriate wall, but only with reference to the bar (not general appliances).
I have attempted to print out each application of spacing/positioning/sizing rules for verification purposes - by doing this, I located a few bugs (e.g. a missing "." resulted in the incorrect pairing of corner appliances) and have corrected them. No doubt we will continue to find results that either call for revision of the rules or fixing of coding errors. The actions print out probably is slowing the initial load time.
UPDATED - 9/8/02: Changed the island rule application order to guarantee the appropriate minimums. Also fixed the condition where there are no appliances on the island, but there are appliances on the counter.
Created some custom functions to deal with the drag properties of the breakfast bar, apart from the appliance drag properties. Bar attaches to the back of shape counters and to the front of island counters, attaching adjacent to each and resizing to match their width.
Next need to register bar with counter in order to restrict dragging of appliances if there is an attached bar on the island and to apply the apprioriate island spacing rules. Should also start integraing the room component, to determine whether a breakfast bar can be attached to the counter or a wall blocks it.
Island positioning and counter sizing based on presence of outer counters, presence of overlapping/non-overlapping appliances on opposing counter-island-counter pairs. The sizing actions are reported in a text area to the left of the design for verification purposes.
Checking for bar condition, but need to make bar option available before rules can be applied.
After checking with Xiaoyi, applied island-counter rules for minimum distance between counter-counter (where no appliances exist on either) in the no-island condition and island-wall rules for minumum distance between counter-wall in the no-island condition. May be helpful to try to condense rule application into one routine that can work for the island or no island condition.
There is an issue with the order of application of rules - applying rules in one direction, say depth, can affect whether rules are applied in the opposite direction, say width. To address this issue, we have placed rule application priority on counters 1 and 3, thus altering the depth before determining width.
The wall question remains... next need to try to condense code, add a bar object so that those rules can be tested, add either a room with walls to the layout or just wall/non-wall status to counters. May ultimately be helpful to have all sizing routines also in php, to provide long list of shape and island dimensions.
Island positioning based on presence of outer counters, using formulas provided through the php script.
Next step is to check whether there are parallel appliances or a bar condition. Will require a routine for checking overlapping appliances for opposite counters.
Question about how to size island when there is an adjoining space (dining area), rather than a wall - should the island be sized to end in parallel with the side counters? Or is there benefit to recognizing an invisible boundary and using the wall-island distance?
Notes on the sizing and positioning of the island - to be implemented next, following the completion of routine to check whether appliances are parallel.
The onload check now covers both the description information and the layout - it should not proceed until the description information is obtained, the rules are loaded and set, and the appliances movies are loaded and ready for placement.
Next need to work on the island!
Enter the design code and retrieve the appropriate description information. Displays a "one moment please" movie until the design information has been loaded from a php script.
Next need to combine this with a load check for the layout, which will be slightly more complicated. For text file or CGI scripts, "isloaded" can be set to true "on (data)". For the layout, the appliance movies must all be loaded, the rules received and set, and the orient appliance code executed before the layout is "ready".
Still working out load-order bugs...
UPDATE 9/10 - using new load technique and updates rule application
Get description from list of good designs by code identification.
Will next use loaded description to display appropriate design.
UPDATED 9/9 - Am now splitting the design file by carriage return and newline, rather than just newline. This appears to fix a problem with Flash misinterpreting certain values.
Appliances can now be positioned by drag alone and then spaced according to the dimension rules. First select a shape, the comfort level, and the family size. Then drag appliances onto the shape. Hit the "play" green gel button to get the appropriate sizing and spacing for the shape and appliance ordering you have configured. The the up-arrow button by the text-field will let you see the current spacing dimensions at any time, before or after the rules have been applied.
To accomplish this, I am keeping appliance arrays for each counter. On the start of a drag, an appliance is removed from its "parent" counter's array. On stop drag, the appliance is added to its new "parent" counter's array and that array is sorted by relative position. This enables the shape to know the order of appliances so that the appropriate spacing rules can be applied.
The find-nearest function, when appliances are dropped out side the bounds of the counters, has also been improved to use a "spiral" searching technique to locate the nearest counter.
The basic parameters and formulas have been segregated into separate files - the script simply reads the files and executes the formulas.
Still some lingering questions about how best to store this information, whether there are unnecessary duplications, and finally, as Xiaoyi makes modifications, whether it would be worthwhile to create a visual interface for setting rules. Such an interface would require the ability to make formulas that included shape and spacing constants, "maximum of", "minimum of" comparisions, and literal additions/subtractions.
It will be interesting as we develop "human dimensions" and "appliance use" evaluation tools... what kind of functional rules result?
UPDATED 9/9 - Am now splitting the formula files by carriage return and newline, rather than just newline. This appears to fix a problem with Flash misinterpreting certain values.
Change the comfort level and family size from the interface and get the appropriate spacing for your layout configuration using the PHP script developed below. Designed to help us determine whether the dimensions are both being interpreted correctly and make sense based on visual inspection.
There may occasionally be a delay needed between changing the comfort and family size variables and applying the rules, while the loadDims function calls the PHP script - how to signal this visually so users won't be irritated or confused?
Surprisingly, seems to be able to access php file even if flash is not on server - this is contrary to what I read on the web, so just thought I'd note it. Makes debugging off the server easier.
Also note that this movie is 57Kb - the largest yet. That still seems fairly reasonable and I think the Flash-supplied buttons and menu clips are a significant portion of that, so we may be able to reduce it when we have our own control clips. However, it will likely be necessary to start considering load order so that users on slow connections can see something and possibly get started before having to wait for the entire movie to load.
Using basic parameters and formulas worked out by Xiaoyi, this script produces the adjacent,corner, and parallel appliance spacing and counter/wall/window boundary spacing for each comfort level and the minimum and maximum adjacent, corner, and parallel values (regardless of comfort level). The format of the output is what would be needed for use by the Flash movie.
Currently segregating out basic parameters, but hardcoding formulas - would it better to segregate out the formulas as well? How to read in appropriately?
Xiaoyi has designed this from with intial questions to determine the initial state of the guided section and to provide variables that we will use throughout the appliacation for customization.
On submit, the questions output to a PHP file.
UPDATED 8/22/02 - comfort level and design start level calculations and display
Within the guided process, the user is posed with the choice of transitioning to the "II" or the "L" layout shape from the "I" shape; both represent more counter space. To distinguish between these layouts, we believe the critical variable is whether there are multiple cooks - a single cook can make effiicent use of parallel spaces, however, when there are multiple cooks, parallel spaces put them back-to-back, blocking each other from field of view and consequently making meal coordination and social conversation more difficult. To demonstrate this idea, I developed a "field of view" evaluation tool, consisting of an individual, from top view, who rotates his head from left to right, illuminating what parts of the kitchen are easily within view.
I am working to make them draggable, so users can run their own tests.
Set the comfort level spacing from the radio button options - [A],[B],[C]. The resulting configurations represent the dimension rules read from the appropriate text files. These should represent dimensions for the 3-4 person family. In the completed tool, the preamble questions should determine the comfort level and family size and these values will be sent to the layout so it can use the appropriate text file and dimension rules. It is also possible that the user can change these settings during the tinkering stage - deciding, for example, that he/she would like a more luxurious kitchen and needing the appropriate evaluation guidelines.
I may need to work some with loading order to make sure nothing gets called before the data is available - either the dimensions, the appliance movies, or the code... some sort of "wait loop" may be required.
Updated 8/20/02 - Added textarea to output dimensions: both width and depth and appliance offsets. The user can also nudge the appliances (on the same counter) and update the textarea to reflect the modifications. Next need to track when the appliances are moved to a new counter and begin "evaluating" spacing to determine whether any dimension guidelines are being violated.
Using essentially the same object-code as the counter layout, the room object has draggable windows and doors and can be sized based on their placement or on a set width/depth. The shape layout is placed within the room to show the value (or detraction?) of the room context. To consider for the future - should the layout "attach" to the room? Should the room automatically resize to match the shape, at least for the guided stage? What kind of resize tabs should be available for the room and layout during the tinkering stage? How should that involve the interaction of room and layout elements be handeled (appliance on counter ending at wall, appliance next to window)?
Appliance placement and counter sizing based on Xiaoyi's adjacency and corner rules. Specify the shape ("G shape") and appliance assignment (counter1="sd", counter2="fo") and view the resulting configuration. Based on [A] level for 3-4 person families. Next step need to read from file and consider wall-counter interactions. Also need to determine what to do about parallel rules.
Intermediary version of appliance placement and counter sizing based on Xiaoyi's adjacency and corner rules. Note that appliances are outside of counters, but at their correct spacing. Next step will be to update a few routines so the appliances align with the counters. Also need to consider entry and wall conditions for counters.
Combined the shape and island objects to create a more complete dragging environment. Need to create a simpler way to initially place appliances. Find nearest is giving the shape priority over island - might be possible to make a comparison (the nearest island counter versus the nearest shape counter), but for now seems like an acceptable shortcut.
Breakfast bars are set to attach to exterior of counter shapes, and consequently do not do well on the island object. Need to get this working with both shapes, while also attending to issues discussed below.
The same method to drop appliance objects on counters can be used to attach breakfast bars to the island counters. However, the situation will be slightly different for non-island counters, where the island attaches adjacent to the counter. Additionally, the drag properties of the attached counter, whether island or shape, need to change and the bar needs to be appropriately resized. This will require an "on drop" procedure customized for both objects.
Each tool might have an interface that introduces the tool's purpose, frames the usage, collects data for both research and customization, and primes the user for effectively evaluating with the tool. For the footstep tool, one might collect height data to customize the tool (if we can find a relatively accurate formula that is signficant) and collect data about a user's current kitchen, while priming them for understanding footstep measurements. For this tool, the questions about the current kitchen encourage the user to reflect and realize that they already have tools (their own bodies) for evaluating spaces.
Drag sink appliance on island shape and have snap-to anywhere, centered, or aligned with a subsection edge. Note that the island is made up of 4 counters, with their "back" edges in the center.
Next will need to consider multiple "surface" objects, such as both a counter shape and island and how to keep track of varied anchor requirements, based on the placed object and the surface object.
During the guided stage, users will have a limited number of transition options, such as "more counter" or "cooktop near breakfast bar," at any given state. For each transition, we want to provide usability and accessibility related information to help users make these decisions. The information should be in a format to which users can relate - actual scenarios they have experienced or can imagine.
These "stories" can also help us develop useful evaluation tools. For example, several transitions have to do with "line of sight" - what can the cook see when in the kitchen? What can the cook seen when in the adjoining space or hallway? A possible evaluation tool might help users evaluate what an individual can see of other cooks (to coordinate meals) and appliances (to detect something burning) at critical locations in the kitchen and adjoining areas. An image demonstrating this is at the bottom of the linked page.
Some notes and images on adjacency, particularly with respect to adding the breakfast bar object to counters and the island. Each child object should be further constrained by its parent object (counter within island, island within shape, shape within room) - for adjacency, this means limiting the anchor points for attachment. However, each child object may also have some additional routines that must be called on attach or detach. For example, the island's dragging spaces change with the addition of a breakfast bar; it should not be possible to place a sink on the counter space directly adjacent to the bar (it would be impossible to reach). To accommodate this, the best option would be for that drag region to shrink, while the opposite drag region resizes to compensate - while maintaining the original island dimensions. On detachment, the drag regions of the island need to return to their original state.
One approach to creating a simple mock-up of the guided stage is to not worry about animation and to "hard code" transitions and text. This is an example of a few states and transitions. Each frame of the movie represents one state and sets the visibility of the counters, the length of the counters, the visibility of the breakfast bar, the visibility of the island, and the placement of the appliances. Available transitions are represented here as direct commands ('more counter'), but could also easily be simple stories.
Although the construction is somewhat tedious, and certainly not extensible, this could allow us to relatively quickly create a mock-up that represents the guided local search idea. Alternatively, as a next stage we could focus on implementing the parametric rules, which are of primary importance to the tinkering stage, but may also be used during the guided stage to layout out the pre-ordered sequence of appliances for each state.
Note - need to at some point make sure the relative dimensions of each of the appliances makes sense - the refrigerator, for example, seems too wide.
Drag dishes to evaluate the length of counters or the spacing between appliances. Use the footstep tool to measure the distance that must be walked between appliances.
Improvement possibilities include providing the user with actual dimensional information as they use the tools - "that was about 5 steps, or 123 inches." The footstep tool should perhaps be aware of the context - not allowing footsteps on counters or having a side-by-side option for appliances on the same counter.
How to explain or demonstrate how the tool should be used? Perhaps an animated demo with simulated hand clicking and dragging?
7/31/02 update - noticed at home, a lag on appliance drop to placement/orientation - the source of the problem is actually how I am updating the scene on "mouse move." At home, where I have a higher precision mouse, it's not uncommon for my cursor to remain static when I unclick. Although this problem would likely not be apparent in most real-use situations, I believe I will go ahead and move the update to "on frame" rather than relying on mouse movement.
Also thought of an idea where we might have a "customize" the evaluation tool form, where the user might enter, for example, his/her height, to get a custom stride. The user could also be asked to report or estimate the numberof strides between sink and refrigerator in his/her current kitchen. This would help the the user make an explicit link between what he/she is seeing on the screen (foot stride) and the real world, as well as provide us with another source of information - how many strides does the average user report?
Would also like to think about other types of evaluation tools. For example, how do we get people to make useful comparisons with their current kitchen or their parents' kitchen (are they just replicating what is familiar? is that what they really want?) Would it be helpful to provide drag-n-drop counter appliances so users can think about where they would place them - creating more complex and accurate work stations (e.g. the mixer and food processor are as important as the cooktop to a baker's work routine, the microwave is of primary importance to many American families).
Created to test the animation routines and make some decisions about what to embed in the shape object. Unfortunately, requires the user be very patient and not make another choice before the animation completes, if the animation works on the same counter (shrinking, growing). The issue has to do with resize requests using an intermediary width (grow to xxx, where xxx is the width in the middle of a shrink). To remove this problem, I believe I need to keep some counter width variables at the shape level, rather than relying on the current width of the counter for requests.
Need to work more on the most complex animation sequence L to I.
Later on, may add option of having a wheelchair next to the chairs and resize according to # of chairs needed.
Am hoping to work out a way to drag-n-drop breakfast bar so that it will snap-attach to back edge of counterspace. Resize handle - making intuitive for inexperienced users may be challenging.
Improvement on the snap-to dragging - when the appliance object is dropped outside of a counter, it finds the nearest counter and orients and snaps accordingly.
Also included some counter offset information, so that an object placed in the right-hand corner of a counter will be pushed to a non-corner position. Need to decide the best way to do this for the other edge
Am also contemplating segregating out the appliances from the counter-shape, which will require a more complex drop routine, but should allow for more complex drag and snap behavior.
The user is now free to drag the appliance objects anywhere, without being constrainted by direction. As the mouse moves, the appliance object checks whether its center point is "in bounds" of a counter object; if not, the alpha transparency is dropped to 50%, creating a ghost-like appearance.
If the object is dropped on a counter, it orients to to the counter and "snaps" to the corresponding point on the counter midline. If the object is dropped outside a counter, it is returned to its previous counter, but possibly in a new position along the midline axis.
Can be employed in initial placement of appliances, but will be of primary use when a design state change requires the re-ordering or shifting of appliances.
Need to decide the best way to read-in appliance positions - counter + offset? Will need to encapsulate animation routine to make swapping more straightforward.
Rotate and resize, coordinating counters and appliances. Rotate is actually a rotate animation followed by a reset and shape change, updating the visible counters and the appliance positions.
Wanted to provide drag "tracks" and automatic orientation to make gross mistakes, such as a sink floating in space or a refrigerator with its doors to the wall, less likely. In this implementaiton, that works for same counter dragging, but the leap from counter to counter is problematic, due to change in the appliance's position relative to the user's cursor - thus the blinking at corners. Will need to consider remedies or an alternative approach.
Rather than simply scaling a bitmap to fit the counter, each appliance will be a small flash movie, with its own methods for resizing and animating. For the refrigerator, resizing involves both the body dimensions and the appropriate door dimensions. Its simple animation is that of the doors opening or closing.