diff options
Diffstat (limited to 'src/scraping')
| -rw-r--r-- | src/scraping/buxton/json/buxton.json | 145 | ||||
| -rw-r--r-- | src/scraping/buxton/json/incomplete.json | 95 | ||||
| -rw-r--r-- | src/scraping/buxton/node_scraper.ts | 90 |
3 files changed, 4 insertions, 326 deletions
diff --git a/src/scraping/buxton/json/buxton.json b/src/scraping/buxton/json/buxton.json index 166f4bd49..8371f2cf2 100644 --- a/src/scraping/buxton/json/buxton.json +++ b/src/scraping/buxton/json/buxton.json @@ -44,54 +44,6 @@ "longDescription": "First released in 2003 with a PS/2 connector (ACK-540PW & ACK-540PB). USB version released in 2006 in either black (ACK-540UB) or white (ACK-540UW). Marketed under different brands, including SolidTek: http: //www. tigerdirect. com/applications/searchtools/item-details. asp? EdpNo=1472243https: //acecaddigital. com/index. php/products/keyboards/mini-keyboards/kb-540 Deltaco: https: //www. digitalimpuls. no/logitech/116652/deltaco-minitastatur-med-touchpad-usb" }, { - "title": "Braun AG T3 Transistor Radio", - "company": "Braun AG", - "year": 1958, - "primaryKey": [ - "Radio" - ], - "secondaryKey": [ - "Handheld", - "Object", - "Reference" - ], - "originalPrice": 28.57, - "degreesOfFreedom": 2, - "dimensions": { - "length": 152, - "width": 41, - "height": 83, - "unit": "mm" - }, - "shortDescription": "The 1958 Braun T3 transistor radio, designed by Dieter Rams Dieter Rams in conjunction with the Ulm Hochschüle fur Gestaltung (School of Design). An excellent example of the international style of design of the mid-20th century, the T3 radio was the inspiration for the design language of the Apple iPod Classic.", - "longDescription": "The 1958 Braun T3 transistor radio is a classic of the international design style prevalent in the mid-20th century. By its sparse clean lines, it shares characteristics of the style seen in another familiar example, the font Helvetic, which was designed the previous year. The T3 was designed by Dieter Rams, recruited by Braun in 1955, in collaboration with the Ulm Hochschüle fur Gestaltun. . Its design language had a strong influence on that of the original Apple iPod Classic. The connection is made more obvious if one views the radio rotated 90° clockwise, as in one of the accompanying photographs. Here one can easily see the the similarity of proportions, uniformity of colour, angle of corners, location of display (audio versus visual), and the use of a flush rotary wheel controller." - }, - { - "title": "Casio CZ-101 Digital Synthesizer", - "company": "Casio", - "year": 1984, - "primaryKey": [ - "Synthesizer" - ], - "secondaryKey": [ - "Chord", - "Keyboard", - "Object", - "Reference", - "Wheel" - ], - "originalPrice": 499, - "degreesOfFreedom": 1, - "dimensions": { - "length": 20, - "width": 65.7, - "height": 58, - "unit": "mm" - }, - "shortDescription": "One of the first programable polyphonic (8 simultaneous voices) digital synthesizers for less than $500. 00. Used a form of digital synthesis known as Phase Distortion to obtain a rich variety of dynamic timbres. Could be used with batteries or plugged in to power. This one was given to me at the product launch.", - "longDescription": "One of the first programable polyphonic (8 simultaneous voices) digital synthesizers for less than $500. 00. Used a form of digital synthesis known as Phase Distortion to obtain a rich variety of dynamic timbres. Could be used with batteries or plugged in to power. This one was given to me at the product launch. The inclusion of this synthesizer in the collection is as a small reminder of the diversity of keyboard types, and especially, as an example to shed light on chord keyboards. In entering text, for example, chord keyboards are those where more than one key must be simultaneously pressed to enter a single character. Technically, this includes any keyboard with a SHIFT key. Interestingly, piano-type like keyboards like that on the Casio-CZ-101 probably don’t conform to this definition of chording, despite its ability to play musical chords. On the other hand, flutes and trumpets definitely do fall within the definition. Why? With piano-like keyboards, each unique note has a single unique key dedicated to it. When one plays a chord, i. e. , simultaneously presses multiple keys, the result is a chord of notes – the note associated with each depressed key sounds. On the other hand, with trumpet valves or flute keys, only one note is produced at a time. It is the combination of keys pressed (coupled with breath) which determines the pitch of that single note. This is far closer to entering text with a chord keyboard, where each chord enters a single unique character." - }, - { "title": "Contour Design UniTrap ", "company": "Contour Design", "year": 1999, @@ -137,32 +89,6 @@ "longDescription": "DePraz began manufacturing in 1980, but following design built in 1979. Logitech started selling it in 1982. It was one of the first mass produced mice, one of the first available ball mice, as well as to have an optical shaft encoder – thereby improving linearity. An interesting fact, given its Swiss heritage, is that its designer, André Guignard, was trained as a Swiss watch maker. Unlike most modern mice, the DePraz, or “Swiss” mouse had a quasi-hemispherical shape. Hence, it was held in a so-called “power-grip”, much as one would grip a horizontally held ball – the thumb and small finger applying pressure on each side, with added support from the weight/friction of the palm on the back of the mouse. In this posture, the three middle fingers naturally positioning themselves over the three buttons mounted at the lower edge of the front. Largely freed of grip pressure, by grace of thumb and little finger, the middle fingers had essentially freedom of motion to independently operate the buttons. Each having a dedicated finger, the buttons could be easily pushed independently or in any combination. Like the three valves on a trumpet, this ability to “chord” extended the three physical buttons to have the power of seven. The down-side of this “turtle shell” form factor is that it placed the hand in a posture in which mouse movement relied more of the larger muscle groups of the arm to wrist, rather than wrist to fingers – the latter being the approach taken in most subsequent mice. The original Swiss Mouse was developed at École Polytechnique Fédérale de Lausanne by a project led by Jean-Daniel Nicoud, who was also responsible for the development of its optical shaft encoder. To augment their revenue stream, Logitech, then a software and hardware consulting company for the publishing industry, acquired marketing rights for North America. Mouse revenue quickly overshadowed that from software. In 1983, Logitech acquired DePraz, named the Swiss Mouse the “P4”, and grew to become one of the largest input device manufacturer in the world. One curious coincidence is that they were founded in the town of Apples, Switzerland." }, { - "title": "FingerWorks TouchStream LP", - "company": "FingerWorks", - "year": 2002, - "primaryKey": [ - "Keyboard" - ], - "secondaryKey": [ - "Foldable", - "Gesture", - "Keyboard", - "Multi-touch", - "Reskin", - "Touchpad" - ], - "originalPrice": 339, - "degreesOfFreedom": 2, - "dimensions": { - "length": 180, - "width": 140, - "height": 9, - "unit": "mm" - }, - "shortDescription": "The TouchStream is a keyboard based on a pair of multi-touch pads. These can sense key taps and finger gestures. The “keys” are graphic. They are flush with the pad and have no mechanical movement. There are however, small raised points to help position the hands on the keyboard eyes-free typing, but these still allow the fingers slide easily on the surface when gesturing, such as when emulating a mouse. . The keyboard is independent of the base. It can be folded in half for compact portability. It can also be placed conveniently over a laptop’s keyboard as a replacement which then also enables the gesture enhancements to be used on the road. Although not obvious to the eye, this is the core technology which, after being acquired by Apple, evolved into the iPhone’s multi-touch capability.", - "longDescription": "Named FingerBoard during development, this product was relabeled TouchStream in October 2001 as the release date approached. when finally shipped, was renamed TouchStreamThe very rare original stand for this device was a gift from Sean Gerety, Atlanta, GA." - }, - { "title": "One Laptop Per Child (OLPC) XO-1", "company": "One Laptop Per Child (OLPC)", "year": 2007, @@ -186,76 +112,5 @@ }, "shortDescription": "The OLPC XO-1 is very innovative device that nevertheless raises serious issues about technology and social responsibility. It is included in the collection primarily as a warning against technological hubris, and the fact that no technologies are neutral from a social-cultural perspective.", "longDescription": "IntroductionI have this computer in my collection as a reminder of the delicate relationship between object and purpose, and how no matter how well one does on the former, it will likely have no impact on making a wanting concept achieve the stated (and even valid) purpose any better. I include it in the collection as a cautionary tale of how the object may help sell a concept, regardless how ill-conceived – even to those who should know better, had they applied the most basic critical thinking. For consumers, investors and designers, its story serves as a cautionary reminder to the importance of cultivating and retaining a critical mind and questioning perspective, regardless of how intrinsically seductive or well-intentioned a technology may be. From the perspective of hardware and software, what the One Laptop Per Child (OLPC) project was able to accomplish is impressive. In general, the team delivered a computer that could be produced at a remarkably low price – even if about double that which was targeted. Specifically, the display, for example, is innovative, and stands out due to its ability to work both in the bright sun (reflective) as well as in poorly lit spaces (emissive) – something that goes beyond pretty much anything else that is available on today’s (2017) slate computers or e-readers. In short, some excellent work went into this machine, something that is even more impressive, given the nature of the organization from which it emerged. The industrial design was equally impressive. Undertaken by Yves Behar’s FuseprojectUltimately, however, the machine was a means to an end, not the end itself. Rather than a device, the actual mission of the OLPC project was: … to empower the world's poorest children through education. Yet, as described by in their materials, the computer was intended to play a key role in this: With access to this type of tool [the computer], children are engaged in their own education, and learn, share, and create together. They become connected to each other, to the world and to a brighter future. Hence, making a suitable computer suitable to that purpose and the conditions where it would be used, at a price point that would enable broad distribution, was a key part of the project. The Underlying Belief System of the OLPC ProjectSince they are key to the thinking behind the OLPC project, I believe if fair to frame my discussion around the following four questions: Will giving computers to kids in the developing world improve their education? Will having a thus better-educated youth help bring a society out of poverty? Can that educational improvement be accomplished by giving the computers to the kids, with no special training for teachers? Should this be attempted on a global scale without any advance field trials or pilot studies? From the perspective of the OLPC project, the answer to every one of these questions is an unequivocal “yes”. In fact, as we shall see, any suggestion to the contrary is typically answered by condescension and/or mockery. The answers appear to be viewed as self-evident and not worth even questioning. Those who have not subscribed to this doctrine might call such a viewpoint hubris. What staggers me is how the project got so far without the basic assumptions being more broadly questioned, much less such questions being seriously addressed by the proponents. How did seemingly otherwise people commit to the project, through their labour or financial investment, given the apparently naïve and utopian approach that it took? Does the desire to do good cloud judgment that much? Are we that dazzled by a cool technology or big hairy audacious goal? Or by a charismatic personality? To explain my concern, and what this artifact represents to me, let me just touch on the four assumptions on which the project was founded. Will giving computers to kids in the developing world improve education? The literature on this question is, at best, mixed. What is clear is that one cannot make any assumption that such improvements will occur, regardless of whether one is talking about the developing world or suburban USA. For example, in January 2011, The World Bank published the following study: Can Computers Help Students Learn? From Evidence to Policy, January 2011, Number 4, The World Bank. A public-private partnership in Colombia, called Computers for Education, was created in 2002 to increase the availability of computers in public schools for use in education. Since starting, the program has installed more than 73, 000 computers in over 6, 300 public schools in more than 1, 000 municipalities. By 2008, over 2 million students and 83, 000 teachers had taken part. This document reports on a two-year study to determine the impact of the program on student performance. Students in schools that received the computers and teacher training did not do measurably better on tests than students in the control group. Nor was there a positive effect on other measures of learning. Researchers did not find any difference in test scores when they looked at specific components of math and language studies, such as algebra and geometry, and grammar and paraphrase ability in Spanish. But report also notes that results of such studies are mixed: Studies on the relationship between using computers in the classroom and improved test scores in developing countries give mixed results: A review of Israel’s Tomorrow-98 program in the mid-1990s, which put computers in schools across the country, did not find any impact on math and Hebrew language scores. But in India, a study of a computer-assisted learning program showed a significant positive impact on math scores. One thing researchers agree on, more work is needed in this field. Before moving on, a search of the literature will show that these results are consistent with those that were available in the literature at the time that the project was started. The point that I am making is not that the OLPC project could not be made to work; rather, that it was wrong to assume that it would do so without spending at least as much time designing the process to bring that about, as was expended designing the computer itself. Risk is fine, and something that can be mitigated. But diving in under the assumption that it would just work is not calculated risk, it is gambling - with other people’s lives, education and money. Will a better educated population help bring a society out of poverty? I am largely going to punt on this question. The fact is, I would be hard pressed to argue against education. But let us grant that improving education in the developing world is a good thing. The appropriate question is: is the approach of the OLPC project a reasonable or responsible way to disburse the limited resources that are available to address the educational challenges of the developing world? At the very least, I would suggest that this is a topic worthy of debate. An a priori assumption that giving computers is the right solution is akin to the, “If you build it they will come” approach seen in the movie, Field of Dreams. The problem here is that this is not a movie. There are real lives and futures that are at stake here – lives of those who cannot afford to see the movie, much less have precious resources spent on projects that are not well thought through. Can that improvement be accomplished by just giving the computers to the kids without training teachers? Remarkably, the OLPC Project’s answer is an explicit, “Yes”. In a TED talk filmed in December 2007, the founder of the OLPC initiative, Nicholas Negroponte states: “When people tell me, you know, who’s going to teach the teachers to teach the kids, I say to myself, “What planet do you come from? ” Okay, there’s not a person in this room [the TED Conference], I don’t care how techy you are, there’s not a person in this room that doesn’t give their laptop or cell phone to a kid to help them debug it. Okay, we all need help, even those of us who are very seasoned. ”Let us leave aside the naïvete of this statement stemming from the lack of distinction between ability to use applications and devices versus the ability to create and shape them. A failure of logic remains in that those unseasoned kids are part of “us”, as in “we all need help”. Where do the kids go for help? To other kids? What if they don’t know? Often they won’t. After all, the question may well have to do with a concept in calculus, rather than how to use the computer. What then? No answer is offered. Rather, those who dare raise the serious and legitimate concerns regarding teacher preparation are mockingly dismissed as coming from another planet! Well, perhaps they are. But in that case, there should at least be some debate as to who lives on which planet. Is it the people raising the question or the one dismissing the concern that lives in the real world of responsible thought and action? Can this all be accomplished without any advance field trials? Should one just immediately commit to international deployment of the program? As recently as September 2009, Negroponte took part in a panel discussion where he spoke on this matter. He states: I'd like you to imagine that I told you \"I have a technology that is going to change the quality of life. \" And then I tell you \"Really the right thing to do is to set up a pilot project to test my technology. And then the second thing to do is, once the pilot has been running for some period of time, is to go and measure very carefully the benefits of that technology. \"And then I am to tell you that what we are going to is very scientifically evaluate this technology, with control groups - giving it to some, giving it to others. And this all is very reasonable until I tell you the technology is electricity. And you say \"Wait, you don't have to do that!\"But you don't have to do that with laptops and learning either. And the fact that somebody in the room would say the impact is unclear is to me amazing - unbelievably amazing. There's not a person in this room who hasn't bought a laptop for their child, if they could afford it. And you don't know somebody who hasn't done it, if they can afford it. So there's only one question on the table and that's, “How to afford it? ” That's the only question. There is no other question - it's just the economics. And so, when One Laptop Per Child started, I didn't have the picture quite as clear as that, but we did focus on trying to get the price down. We did focus on those things. Unfortunately, Negroponte demonstrates his lack of understanding of both the history of electricity and education in this example. His historical mistake is this: yes, it was pretty obvious that electricity could bring many benefits to society. But what happened when Edison did exactly what Negroponte advocates? He almost lost his company due to his complete (but mistaken) conviction that DC, rather the AC was the correct technology to pursue. As with electricity, yes, it is rather obvious that education could bring significant benefits to the developing world. But in order to avoid making the same kind of expensive mistake that Edison did, perhaps one might want to do one’s best to make sure that the chosen technology is the AC, rather than DC, of education. A little more research, and a little less hubris might have put the investments in Edison and the OLPC to much better use. But the larger question is this: in what way is it responsible for the wealthy western world to advocate an untested and expensive (in every sense) technological solution on the poorest nations in the world? If history has taught us anything, it has taught us that just because our intentions are good, the same is not necessarily true for consequences of our actions. Later in his presentation, Negroponte states: … our problems are swimming against very naïve views of education. With this, I have to agree. It is just whose views on education are naïve, and how can such views emerge from MIT, no less, much less pass with so little critical scrutiny by the public, the press, participants, and funders? In an interview with Paul Marks, published in the New Scientist in December 2008, we see the how the techno-centric aspect of the project plays into the ostensible human centric purpose of the project. Negroponte’s retort regarding some of the initial skepticism that the project provoked was this: “When we first said we could build a laptop for $100 it was viewed as unrealistic and so 'anti-market' and so 'anti' the current laptops which at the time were around $1000 each, \" Negroponte said. \"It was viewed as pure bravado - but look what happened: the netbook market has developed in our wake. \" The project's demands for cheaper components such as keyboards, and processors nudged the industry into finding ways to cut costs, he says. \"What started off as a revolution became a culture. \"Surprise, yes, computers get smaller, faster, and cheaper over the course of time, and yes, one can even grant that the OLPC project may have accelerated that inevitable move. And, I have already stated my admiration and respect for the quality of the technology that was developed. But in the context of the overall objectives of the project, the best that one can say is, “Congratulations on meeting a milestone. ” However, by the same token, one might also legitimately question if starting with the hardware was not an instance of putting the cart before the horse. Yes, it is obviously necessary to have portable computers in the first place, before one can introduce them into the classroom, home, and donate them to children in the developing world. But it is also the case that small portable computers were already in existence and at the time that the project was initiated. While a factor of ten more expensive than the eventual target price, they were both available and adequate to support limited preliminary testing of the underlying premises of the project in an affordable manner. That is, before launching into a major - albeit well-intentioned – hardware development project, it may have been prudent to have tested the underlying premises of its motivation. Here we have to return to the raison d’être of the initiative: … to empower the world's poorest children through educationHence, the extent to which this is achieved from a given investment must be the primary metric of success, as well as the driving force of the project. Yet, that is clearly not what happened. Driven by a blind Edisonian belief in their un-tested premise, the project’s investments were overwhelmingly on the side of technology rather than pedagogy. Perhaps the nature and extent of the naïve (but well-meaning) utopian dream underlying the project is captured in the last part of the interview, above: Negroponte believes that empowering children and their parents with the educational resources offered by computers and the Internet will lead to informed decisions that improve democracy. Indeed, it has led to some gentle ribbing between himself and his brother: John Negroponte - currently deputy secretary of state in the outgoing Bush administration and the first ever director of national intelligence at the National Security Agency. \"I often joke with John that he can bring democracy his way - and I'll bring it mine, \" he says. Apparently providing inexpensive laptops to children in the developing world is not only going to raise educational standards, eradicate poverty, it is also going to bring democracy! All that, with no mention of the numerous poor non-democratic countries that have literacy levels equal to or higher than the USA (Cuba might be one reasonable example). The words naïve technological-utopianism come to mind. I began by admitting that I was conflicted in terms of this project. From the purely technological perspective, there is much to admire in the project’s accomplishments. Sadly, that was not the project’s primary objective. What appears to be missing throughout is an inability to distinguish between the technology and the purpose to which is was intended to serve. My concern in this regard is reflected in a paper by Warschauer & Ames(2010). The analysis reveals that provision of individual laptops is a utopian vision for the children in the poorest countries, whose educational and social futures could be more effectively improved if the same investments were instead made on more sustainable and proven interventions. Middle- and high-income countries may have a stronger rationale for providing individual laptops to children, but will still want to eschew OLPC’s technocentric vision. In summary, OLPC represents the latest in a long line of technologically utopian development schemes that have unsuccessfully attempted to solve complex social problems with overly simplistic solutions. There is a delicate relationship between technology and society, culture, ethics, and values. What this case study reflects is the fact that technologies are not neutral. They never are. Hence, technological initiatives must be accompanied by appropriate social, cultural and ethical considerations – especially in projects such as this where the technologies are being introduced into particularly vulnerable societies. That did not happen here, The fact that this project got the support that it did, and has gone as far as it has, given the way it was approached, is why this reminder – in the form of this device – is included in the collection. And if anyone ever wonders why I am so vocal about the need for public discourse around technology, one need look no further than the OLPC project." - }, - { - "title": "TASA Model 55 ASCII Keyboard", - "company": "TASA (Touch Activated Switch Arrays)", - "year": 1979, - "primaryKey": [ - "Keyboard" - ], - "secondaryKey": [ - "Pad", - "Touch" - ], - "originalPrice": 80, - "degreesOfFreedom": 0, - "dimensions": { - "length": 382.27, - "width": 158.75, - "height": 8.255, - "unit": "mm" - }, - "shortDescription": "This touch-sensitive keyboard is especially suited for super clean environments, such as hospitals, and those which are just the opposite. The reason is that, being completely flat, there are no crack or gaps where dirt or bacteria can accumulate. This same property enables it to be easily cleaned. However, the reason that I got this keyboard because it was silent – there are no mechanical key-clicks. Hence, for example, it enabled me to soundlessly enter data to my digital musical instrument during a concert or while recording.", - "longDescription": "This is a solid-state touch-sensitive keyboard with no moving parts. Because its surface is flat, the only way one knows that it is a QWERTY keyboard is by the graphical representation on its surface. One types by placing one’s fingers on pictures of keys, rather than physical/mechanical keycaps. Because of the lack of the tactile feedback associated with conventional keyboards, as expected, typing speed and/or accuracy will be compromised with this keyboard. And yet, this keyboard brings real value in certain situations, and in so doing, it provides a good example of the rule: Everything is best for something and worst for something else. Because the is especially suited for super clean environments, such as hospitals, and those which are just the opposite. The reason is that, being completely flat, there are no crack or gaps where dirt or bacteria can accumulate. This same property enables it to be easily cleaned. However, the reason that I got this keyboard because it was silent – there are no mechanical key-clicks. Hence, for example, it enabled me to soundlessly enter data to my digital musical instrument during a concert or while recording. This is one of a number of capacitive touch-sensing input devices produced in the period around 1981 by Touch Activated Switch Arrays (TASA). The others included a touch-sensitive linear controller, the Ferinstat, which could function as a linear slider/fader, for applications such as audio or process control. These came in two lengths and are included in the collection. There were also the Model 16 Micro Proximity Keyboards, which were 16-button keyboards, arranged in a 4x4 array of touch-sensitive buttons that included a touch-sensitive numerical keypad. They also demonstrated a small, capacitive touch-sensitive touch pad, not unlike what one sees on today’s laptops, for example." - }, - { - "title": "HandyKey (TekGear) Twiddler ", - "company": "HandyKey (TekGear)", - "year": 1991, - "primaryKey": [ - "Chord", - "Keyboard" - ], - "secondaryKey": [ - "Gesture", - "Joystick", - "Keyboard", - "Reality", - "Virtual", - "Vr", - "Wearable" - ], - "originalPrice": 199, - "degreesOfFreedom": 2, - "dimensions": { - "length": 128, - "width": 45, - "height": 50, - "unit": "mm" - }, - "shortDescription": "The Twiddler is a one-hand chord keyboard with integrated pointing capability, which can control the cursor in a joystick-like manner. This was a favourite device of the early Cyborg wearable-computer community.", - "longDescription": "……. . Note: Lyons, et al. abstract: An experienced user of the Twiddler, a one--handed chording keyboard, averages speeds of 60 words per minute with letter--by--letter typing of standard test phrases. This fast typing rate coupled with the Twiddler's 3x4 button design, similar to that of a standard mobile telephone, makes it a potential alternative to multi--tap for text entry on mobile phones. Despite this similarity, there is very little data on the Twiddler's performance and learnability. We present a longitudinal study of novice users' learning rates on the Twiddler. Ten participants typed for 20 sessions using two different methods. Each session is composed of 20 minutes of typing with multi--tap and 20 minutes of one--handed chording on the Twiddler. We found that users initially have a faster average typing rate with multi--tap; however, after four sessions the difference becomes negligible, and by the eighth session participants type faster with chording on the Twiddler. Furthermore, after 20 sessions typing rates for the Twiddler are still increasing." - }, - { - "title": "Blue Orb Inc. OrbiTouch", - "company": "Blue Orb Inc", - "year": 2002, - "primaryKey": [ - "Joystick" - ], - "secondaryKey": [ - "Keyboard" - ], - "originalPrice": 695, - "degreesOfFreedom": 4, - "dimensions": { - "length": 482.6, - "width": 228.6, - "height": 74.2, - "unit": "mm" - }, - "shortDescription": "On the one hand, this device has the overall footprint of a keyboard, and it is used to enter text. And yet, it is two wide, flat, spring-loaded, self-returning joysticks, which are used to enter characters, rather than the keys that we typically employ. To add to the unconventional nature of this device, one enters text via these two joysticks by means of something called radial menus, one for each hand. And, in keeping with many keyboards, such as those with an integrated touch pad, the OrbiTouch also enables mouse like capabilities, such as pointing and selecting, also by means of one of the joysticks.", - "longDescription": "Keyboards, Joysticks and Hierarchic Radial MenusIntroductionWhen you first look at this device, you might guess that it is some kind of keyboard. It even says so on the box and on the device itself. The keyboard-like footprint might reinforce this notion, as might the alphanumeric characters in the grey ring around the circular orb on the right-hand. On the other hand, if this is a keyboard, where are the keys? Reading the labels more carefully sheds light on the paradox: there are none. This is a “keyless keyboard. ” Yes, this is a contradiction in terms. But it is just such curiosities that make devices like this potentially interesting. Hence, we shall take a reasonably deep dive to see what might be revealed. Let’s start by trying to understand what the rationale was for landing on this particular design. The orbiTouch was developed by an industrial engineering doctoral student at the University of Central Florida, Peter McAlindon. His goal was to develop a means of text entry that minimized hand and wrist motion. The intent was to reduce the incidence of repetitive stress injury. A fair bit of research was undertaken between initial concept and commercial release. This can be accessed online, and doing so is a worthwhile exercise. Let us now turn our eye to the physical device in order to get a sense of where all of this landed. The Physical DeviceThe orbiTouch is dominated by two large circular “orbs. ” To my eye, their form initially practically screamed out, “I am a rotary control - Turn me!” However, appearances can be deceptive. Rather than dials, the orbs turn out to be a pair of a joysticks of a particular type. Rather than the stick-tilting motion typical of most, these “joysticks” are operated by moving them along the horizontal plane. In this they are a close cousins of the Altra Felix and KA Design Turbo Puck, both also in the collection. However, in contrast with the Felix and Turbo Puck, whose handles are “floating” (if you let go, they remain in the position where you released your grip), the orbs are “self-centering. ” That is, when released, internal springs return the orbs to their neutral central “home” position. In this, they behave much like the Gravis joystick in the collection, for example. At a finer level of detail, the orbs are specific class of joystick: “8-way joy-switches”. The term”8-way” indicates that only movement along the 8 main axes of the compass are sensed. As to the word “switch”, think of each orb as 8 switches, any one of which can be turned on by moving the orb in one of the 8 directions. (Conversely, they are turned off when the orb is released and returns to home position). Unlike an analogue joystick, such switches do not, and cannot, report how far or fast the orb has moved in any particular direction, nor how much pressure might be applied in the process. While limited, joy-switches provide a less complex and lower cost solution that are appropriate in situations where this additional data is not needed. There are several examples of joy-switches in the collection, especially video game controllers. One of the most iconic examples is the Atari CX-40 controller, which is a 4-way joy-switch. To recap, the orbiTouch is a bi-manual device for entering text by means of two orb-shaped planer-moving 8-way self-centering joy-switches. Having swallowed that mouth-full, let us now explore how text is entered using such a transducer. Entering TextIn general, a character or function is input by moving the two orbs. Which character or function depends on the direction (if any) each of the orbs has moved. For example, if both the left and right orb move west (left), the character “a” is entered. On the other hand, if the right orb again moves west, but the left one east (right), then the character input is “e”. How or why this is the case can be explained with the help of some images. For easier reading, the figure below shows the labels around the orbs in an exploded view. Notice that for both orbs, there is a label segment for each of its 8 directions. Since the example discussed entering an “a” and an “e”, each of which involved the right orb moving west (left) let’s look at the associated label segment in even more detail. Like all of the label segments for the right orb, this one consists of six areas containing text, each with a distinct background colour: red, yellow, green, orange and blue for the letters A through E, respectively, and black for the region containing “BACKSPACE”. Now look again at previous image and notice that each of these colours matches the label associated with one of the directions of the left orb. Text is entered using a two part process. Moving the right orb to the left/west specifies that you are going to enter one of: a, b, c, d, e, or BACKSPACE. (Like most keyboards, despite the labels on the key-caps being upper case, lower-case characters are entered unless the shift key is depressed. )Moving the left orb in the direction whose label corresponds to the background colour of the desired character causes that character to be entered. Hence, with the right orb held in the left/west position, one can enter the sequence, “abcde”, followed by a Backspace, by sequentially moving the left orb west (red), north-west (yellow), north (green), north-east (orange), east (blue) and south (black). The same technique can then be used to access all the characters and commands found in the right orb’s labels. Special ModesThere is one thing to add at this point: While entering printing characters always requires the use of both orbs, some actions can be performed using the left orb only. This can be inferred by the text that accompanies some of the left orb’s labels. For example, moving the left orb north (green) in quick succession (analogous to a double-click on a mouse), indicates that SHIFT will apply to the next character entered. Likewise, doing the same thing in the south-west (grey) direction applies the Caps Lock mode, i. e. , SHIFT will be applied to all subsequent entries until the mode is cancelled. These one-handed special modes/functions are summarized in the image below. Of these, the only one that I want to discuss at the moment is the ability of the orbiTouch to switch from entering text to controlling the screen cursor. This is done by moving the left orb south (black) twice in quick succession. When this is done, the right orb controls the cursor movement – the cursor moves continuously in the direction that you move the orb. In this, any doubts that you had about me characterizing the orbs as joysticks should disappear, since this cursor control is classic joystick behaviour. One issue of note is that the label describes this as “mouse” not “joystick”, which while understandable, is incorrect. Finally, before moving on to the next topic, note that while the right orb controls the movement of the screen cursor in mouse mode, movement of the left or left/west or right/east is taken as a left and right mouse button press, respectively. Remembering that the premise here is that the hands don’t have to move from the orbiTouch in order switch between typing and pointing tasks. But that doesn’t mean that the overhead in switching between the tasks is removed. One type of overhead is just substituted for another. And, the moded nature of the orbiTouch means that the option of parallel pointing-typing actions are eliminated. Rather than criticism, I mention these points to indicate the need to be mindful of the trade-offs and consequences of different design decisions - consequences that the designer should be aware of. Going Meta: What’s Really Going On? I want to approach doing so by stepping back, and approaching the underlying method of “typing” by going “meta”. That is, I want to jump up a lever of abstraction, beyond the physical device (for the moment), and explain what is going on at the conceptual level. The rest of the text is in much rougher form …. What will be revealed, if we do so, is that text is entered by means of the parallel use of two 8-direction radial menus. So what is a radial menu? These are the neglected cousins of the linear menus that populate conventional graphical user interfaces. The difference is that one makes a selection by the direction of movement, rather than the distance (as in the case with linear menus). It turns out that people can learn these quickly if the directions correspond to the 8 main points of the compass. For example, in a program menu, moving up (North) might mean Print, down (South) could mean Save, and moving down to the right (South East), Save As. Like linear menus, these menus can also be hierarchic. So, for example, after moving South East in order to specify Save As, a stroke to the left (West) might mean that it should be saved as a PDF file, whereas it would be saved as a Plain Text file if the secondary connected stroke was to the right (East). The reason for this brief tutorial on radial menus is that they pretty much define at the conceptual level how text is entered using the orbiTouch. The eight directions that you can move the orbs defines the menu item selected. And, by having the actual output depending on the combination of the selection made by each of the two orbs, the device can perhaps be best described as entering text using a two-level hierarchic radial menu, where menu selections are made using two planar moving 8-way joy switches. That is quite a mouth-full, and it has taken all of the text above to bring us to the point where there is a reasonable chance that it makes sense. And we still haven’t gotten into the details! it uses hierarchic (2-level) radial menus, but where the hierarchy is space multiplexed, rather than time multiplexed. That is, rather than doing one menu selection after the other, you do them simultaneously, by using a different hand to articulate the selection from each of the two menus. (While the text on the description is sparse still, look at the training cards, etc. and the photos on the page. )At the level of the mental model, there is no question in my mind (actually, I shouldn’t say that, because I am supposed to be an objective researcher who needs empirical data to inform decisions, but what the hell!) that you could give someone who knew how to use this device two isotonic joysticks, such as used with a video game controller, and they would be able to enter text just as fast as with this device. Furthermore, I am sure that if one had a slate capable of sensing both touch and stylus simultaneously, I am certain that the skill would transfer equally to using a touch radial gesture in the non-dominant hand, and stylus (or touch) radial gesture with the other. At the basic level, it is a 2-level radial menu, but where each level is operated independently and quasi-simultaneously by a different one of the operator’s two hands. Level 1: Right HandThis lets the operator select one of eight regionsThe label for each region consists of 6 characters (5 printing and one “special)In selecting one of the regions, one is not selecting any one of the characters of that region; rather, they are just indicating that the character that they want is one of the six in that regionEach of the characters in a region has a different background colour: blue, orange, green, yellow, red and black. Level 2: Left HandThis lets the operator select one of eight regionsEach region is labeled by a single colourAmong the colours that label the eight regions are the same ones used as character background colours in the regions of the right-hand control: blue, orange, green, yellow, red and blackBy the left hand selecting one of these six colours, one indicates which character is to be entered from among the six characters in the region indicated by the right hand – the selected character being the one whose background colour corresponds to the colour selected by the left hand. Hence, there are two 8-way, single level radial menus used. I believe it fair to say that it is, nevertheless, a 2 level radial menu, since both need to be used in order to enter one token. In actual fact, things are more complex, since none of the above covers issues such as all of the special character, punctuation, etc. , that do not appear on the labels of the right hand. To keep things brief, this is why only 6 of the left-hand menu options are used in what is discussed above. The other two options are needed to fill in the gaps. And, even then, the device resorts to something like double-clicks to get special modes and capabilities. For example, double clicking the black (south) region of the left hand turns the right-hand dome into a pointing device, i. e. , a mouse substitute for pointing, etc. I went through the – as it turned out – interesting exercise of translating the two parallel depth-1 radial menus of the orbiTouch UI into two different depth-2, breadth-8 hierarchic radial menus. You can see them in the attached images. The one assumes that the LH “dome” as the first-level selection, and then make the second-level selection with the right-hand dome. The other does the opposite, i. e. , the right-hand dome selection is the first level. It is interesting to compare the two with each other, as well as with both the labeling on the orbiTouch and the Quickstart documentation: The RH level-1 version seems easier to get rudimentary understanding compared to the LH due to clustering of letters and numbers on outer menus. Likewise, for the special characters that are the upper case of the numbersThe physical device is fine for letting you hunt-and-peck, so to speak, for characters, but it is useless for numbers, and most special characters. The documentation provided with the Quick Start (attached is not especially useful in terms of providing heuristics for memorization. While the orbiTouch certainly uses radial menus, it decidedly does not employ marking menus. One of the key things missing is the ability to check and correct before committing to an input, and the lack of ability to backtrack to the start, and therefore abort without entering anything. One thing that I have learned from this exercise is the difference that results due to having self-returning joysticks. Gestures don’t have that attribute. It matters esp w. r. t. the last point. What I like about this story, is how looking at something seemingly very different at the right level of abstraction, teaches us/me something new about something I was supposed to be an expert in. That is, that 2-level hierarchic marking menus can be achieved by two simultaneous single-level MMs. This is why I have the collection, and why I love what I do. There is still delight, despite being a 63-year-old geezer grandfather. The orbiTouch Keyless Keyboard was first known as the Keybowl, and the company was formerly known as Keybowl Inc. , and then Blue Orb Inc." } ]
\ No newline at end of file diff --git a/src/scraping/buxton/json/incomplete.json b/src/scraping/buxton/json/incomplete.json index 595412e56..4b05a2a86 100644 --- a/src/scraping/buxton/json/incomplete.json +++ b/src/scraping/buxton/json/incomplete.json @@ -57,20 +57,10 @@ "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured." }, { - "filename": "Amazon_Kindle_Keyboard.docx", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." - }, - { "filename": "Apple_ADB_Mouse.docx", "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured." }, { - "filename": "Apple_Adj_Keyboard.docx", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured.", - "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." - }, - { "filename": "Apple_Mac_Portable-Katy’s MacBook Air-2.docx", "year": "__ERR__YEAR__TRANSFORM__: NaN cannot be parsed to a numeric value.", "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." @@ -80,10 +70,6 @@ "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." }, { - "filename": "Apple_Mac_Portable.docx", - "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." - }, - { "filename": "Apple_Scroll_Mouse.docx", "year": "__ERR__YEAR__TRANSFORM__: NaN cannot be parsed to a numeric value.", "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", @@ -94,16 +80,6 @@ "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." }, { - "filename": "BAT.docx", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured.", - "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." - }, - { - "filename": "Bill_Notes_CyKey.docx", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured." - }, - { "filename": "Brailler.docx", "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", @@ -116,22 +92,12 @@ "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." }, { - "filename": "CasioC801.docx", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." - }, - { "filename": "CasioTC500.docx", "secondaryKey": "ERR__SECONDARYKEY__: outer match wasn't captured.", "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." }, { - "filename": "Casio_Mini.docx", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." - }, - { "filename": "Citizen_LC_909.docx", "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", @@ -189,11 +155,6 @@ "shortDescription": "ERR__SHORTDESCRIPTION__: outer match was captured." }, { - "filename": "FingerWorks_Prototype.docx", - "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." - }, - { "filename": "Freeboard.docx", "secondaryKey": "ERR__SECONDARYKEY__: outer match was captured.", "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", @@ -201,10 +162,6 @@ "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." }, { - "filename": "FrogPad.docx", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured." - }, - { "filename": "FujitsuPalm.docx", "primaryKey": "ERR__PRIMARYKEY__: outer match was captured.", "secondaryKey": "ERR__SECONDARYKEY__: outer match wasn't captured.", @@ -239,24 +196,10 @@ "shortDescription": "ERR__SHORTDESCRIPTION__: outer match was captured." }, { - "filename": "Gavilan_SC.docx", - "company": "ERR__COMPANY__: outer match wasn't captured.", - "year": "__ERR__YEAR__TRANSFORM__: NaN cannot be parsed to a numeric value.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured.", - "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." - }, - { "filename": "Genius_Ring_Mouse.docx", "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." }, { - "filename": "Grandjean_Stenotype.docx", - "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured.", - "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." - }, - { "filename": "HTC_Touch.docx", "year": "__ERR__YEAR__TRANSFORM__: NaN cannot be parsed to a numeric value.", "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured." @@ -330,10 +273,6 @@ "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." }, { - "filename": "Kindle_3G_lighted_cover.docx", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured." - }, - { "filename": "Leatherman_Tread.docx", "primaryKey": "ERR__PRIMARYKEY__: outer match was captured.", "secondaryKey": "ERR__SECONDARYKEY__: outer match wasn't captured.", @@ -393,10 +332,6 @@ "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." }, { - "filename": "Microwriter.docx", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." - }, - { "filename": "Motorola_DynaTAC.docx", "year": "__ERR__YEAR__TRANSFORM__: NaN cannot be parsed to a numeric value.", "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", @@ -404,21 +339,6 @@ "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." }, { - "filename": "MousePen.docx", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." - }, - { - "filename": "NB75D.docx", - "year": "ERR__YEAR__: outer match was captured.", - "primaryKey": "ERR__PRIMARYKEY__: outer match was captured.", - "secondaryKey": "ERR__SECONDARYKEY__: outer match wasn't captured.", - "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", - "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured.", - "shortDescription": "ERR__SHORTDESCRIPTION__: outer match was captured.", - "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." - }, - { "filename": "NewO.docx", "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." @@ -446,21 +366,12 @@ "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." }, { - "filename": "PARCkbd.docx", - "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured." - }, - { "filename": "PadMouse.docx", "secondaryKey": "ERR__SECONDARYKEY__: outer match wasn't captured.", "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." }, { - "filename": "Philco_Mystery_Control.docx", - "originalPrice": "ERR__ORIGINALPRICE__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." - }, - { "filename": "PowerTrack.docx", "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured.", "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." @@ -500,12 +411,6 @@ "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured." }, { - "filename": "The_Tap.docx", - "secondaryKey": "ERR__SECONDARYKEY__: outer match wasn't captured.", - "dimensions": "ERR__DIMENSIONS__: outer match wasn't captured.", - "longDescription": "ERR__LONGDESCRIPTION__: outer match was captured." - }, - { "filename": "Thumbelina.docx", "secondaryKey": "ERR__SECONDARYKEY__: outer match wasn't captured.", "degreesOfFreedom": "ERR__DEGREESOFFREEDOM__: outer match wasn't captured.", diff --git a/src/scraping/buxton/node_scraper.ts b/src/scraping/buxton/node_scraper.ts index 117a0af84..ab6c9dcb2 100644 --- a/src/scraping/buxton/node_scraper.ts +++ b/src/scraping/buxton/node_scraper.ts @@ -1,9 +1,7 @@ import { readdirSync, writeFile, existsSync, mkdirSync } from "fs"; import * as path from "path"; import { red, cyan, yellow, green } from "colors"; -import { Database } from "../../server/database"; import { Opt } from "../../new_fields/Doc"; -import { Utils } from "../../Utils"; const StreamZip = require('node-stream-zip'); export interface DeviceDocument { @@ -104,7 +102,6 @@ function correctSentences(raw: string) { return { transformed: raw }; } -const targetMongoCollection = "newDocuments"; const outDir = path.resolve(__dirname, "json"); const successOut = "buxton.json"; const failOut = "incomplete.json"; @@ -119,7 +116,7 @@ function printEntries(zip: any) { } } -export async function wordToPlainText(pathToDocument: string): Promise<string> { +async function wordToPlainText(pathToDocument: string): Promise<string> { const zip = new StreamZip({ file: pathToDocument, storeEntries: true }); const contents = await new Promise<string>((resolve, reject) => { zip.on('ready', () => { @@ -172,7 +169,7 @@ function capitalize(word: string): string { return word.charAt(0).toUpperCase() + word.slice(1); } -export function analyze(path: string, body: string): AnalysisResult { +function analyze(path: string, body: string): AnalysisResult { const device: any = {}; const segments = path.split("/"); @@ -249,90 +246,11 @@ async function writeOutputFile(relativePath: string, data: any[], total: number, }); } -namespace Doc { - - export async function create<T = any>(fields: T, viewType?: number) { - const dataDocId = Utils.GenerateGuid(); - const dataDoc = { - _id: dataDocId, - fields: { - ...fields, - isPrototype: true, - author: "Bill Buxton" - }, - __type: "Doc" - }; - const viewDocId = Utils.GenerateGuid(); - const viewDoc = { - _id: viewDocId, - fields: { - proto: protofy(dataDocId), - x: 10, - y: 10, - _width: 900, - _height: 600, - _panX: 0, - _panY: 0, - zIndex: 2, - libraryBrush: false, - _viewType: viewType || 4, - _LODdisable: true - }, - __type: "Doc" - }; - await Database.Instance.insert(viewDoc, targetMongoCollection); - await Database.Instance.insert(dataDoc, targetMongoCollection); - return viewDocId; - } - - export function protofy(id: string) { - return { - fieldId: id, - __type: "proxy" - }; - } - - export function proxifyGuids(ids: string[]) { - return ids.map(id => ({ - fieldId: id, - __type: "proxy" - })); - } - - export function listify(fields: any[]) { - return { - fields: fields, - __type: "list" - }; - } - -} - -async function main() { +export async function main() { if (!existsSync(outDir)) { mkdirSync(outDir); } - - const devices = await parseFiles(); - await Database.tryInitializeConnection(); - - const { create, protofy, proxifyGuids, listify } = Doc; - const parentGuid = await Doc.create({ - proto: protofy("collectionProto"), - title: "The Buxton Collection", - data: listify(proxifyGuids(await Promise.all(devices.map(create)))) - }); - const result = await Database.Instance.updateMany( - { "fields.title": "Collection 1" }, - { $push: { "fields.data.fields": { fieldId: parentGuid, __type: "proxy" } } }, - targetMongoCollection - ); - - console.log(result); - console.log(green(`\nSuccessfully inserted ${devices.length} devices into ${targetMongoCollection}.`)); - - Database.disconnect(); - process.exit(0); + return parseFiles(); } main();
\ No newline at end of file |