Whilewe did not even have modeling
languages for watch applications and watch families, it seemed unrealistic to expect to
pick a good solution to a problem that would probably only become apparent once
several families had been built. We thus decided to go with the simplest thing that
could possibly work: there would be a limited number of named buttons, initially just
Up, Down, Mode, and Set. Each physical watch body could contain any combination
of these buttons, and similarly each watch application could refer to them directly.
While less ?¬‚exible than a different mapping for each watch, this had a good chance of
working well for both watch modelers and users. Both groups would prefer a
consistent semantics for the buttons: if in one watch application Up was used to
increase a time value, and in another the same function was achieved using Set,
learning to use the watch would be rather dif?¬?cult!
Now we had a fair idea of the contents and division of labor of the two modeling
languages. The family model would contain a number of watches, and each watch
would be composed there from a number of watch applications and a physical watch
body.Aphysical watch body would specify a number of buttons. These buttons would
also play a key role in the de?¬?nition of the watch applications: different buttons would
cause different actions in different applications.
Pages:
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360