Advances and growth in Internet usage have introduced a new range of manifestations of the ego. Personal home pages are a curious phenomenon; how many of us who happily maintain a home page with biographical information including personal details, opinions and preferences, would consider publishing similar information as a newspaper advertisement? However, in this note I want to restrict my discussion to some issues relating to email, rather than broader Internet usage.
{"title":"Alter the e-go?","authors":"M. Apperley","doi":"10.1145/568190.568202","DOIUrl":"https://doi.org/10.1145/568190.568202","url":null,"abstract":"Advances and growth in Internet usage have introduced a new range of manifestations of the ego. Personal home pages are a curious phenomenon; how many of us who happily maintain a home page with biographical information including personal details, opinions and preferences, would consider publishing similar information as a newspaper advertisement? However, in this note I want to restrict my discussion to some issues relating to email, rather than broader Internet usage.","PeriodicalId":7070,"journal":{"name":"ACM Sigchi Bulletin","volume":"47 1","pages":"8 - 8"},"PeriodicalIF":0.0,"publicationDate":"2002-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"82089344","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Session details: From the editor","authors":"","doi":"10.1145/3263620","DOIUrl":"https://doi.org/10.1145/3263620","url":null,"abstract":"","PeriodicalId":7070,"journal":{"name":"ACM Sigchi Bulletin","volume":"20 1","pages":""},"PeriodicalIF":0.0,"publicationDate":"2002-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"89930833","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Professor Challenger, the hero of Author Conan Doyle's The Lost World, goes in search of a land that time has forgotten. It is a forbidding place, inhabited by dinosaurs, with many hazards for the unwary. Adventurous web users can visit similar lost worlds without risking life or limb. The worlds in question are called e-banking sites. The 'e' is meant to stand for 'electronic', but from my own experience of using these sites both in the US and UK, 'excruciat-ing' would be more accurate. The main problem seems to be that like Doyle's lost world, time has passed many e-banking sites by. The usual rules of web evolution-a form of natural selection-do not apply in these isolated environments. If users get lost or confused they cannot simply switch to another web site. They must confront the monsters head on or change banks. However, in the UK at least, customers are very reluctant to change: a survey in September 2001 found that while 79% of UK account holders have experienced 'frustrating' problems with their bank, only 26% have switched banks. A further 14% would like to switch but see it as being 'too much hassle'. This means that in many cases e-banking web sites are serving a captive audience. Predictably, this becomes very clear if we look at some of the problems that occur: • Belligerent security model. Most e-banking sites I have come across equate inconvenience with security: three or four login screens are not uncommon, yet most of the information requested is in the public domain. I have not yet seen an e-banking site that makes use of stronger security based on certificates or two-factor authentication. Either would be more secure and easier to use, although there are compatibility problems with certificates on some older brows-ers. To add insult to injury, most of the sites with difficult login procedures require full login even if all that is wanted is account balances. • Aggressive navigation. Some Jurassic e-banking sites have bizarre navigation schemes that attempt to disable the browser back button. Unfortunately, absent-minded use of the back-space key by intrepid users spoils this plan and the web site responds with considerable ferocity , typically by closing the browser. (Prehistoric rules of usability dictate that these are normally the sites with the most tortuous login.) • Precambrian design philosophy. While there are higher forms of e-banking that support finance packages such …
{"title":"The lost world of e-banking","authors":"W. Hudson","doi":"10.1145/568190.568200","DOIUrl":"https://doi.org/10.1145/568190.568200","url":null,"abstract":"Professor Challenger, the hero of Author Conan Doyle's The Lost World, goes in search of a land that time has forgotten. It is a forbidding place, inhabited by dinosaurs, with many hazards for the unwary. Adventurous web users can visit similar lost worlds without risking life or limb. The worlds in question are called e-banking sites. The 'e' is meant to stand for 'electronic', but from my own experience of using these sites both in the US and UK, 'excruciat-ing' would be more accurate. The main problem seems to be that like Doyle's lost world, time has passed many e-banking sites by. The usual rules of web evolution-a form of natural selection-do not apply in these isolated environments. If users get lost or confused they cannot simply switch to another web site. They must confront the monsters head on or change banks. However, in the UK at least, customers are very reluctant to change: a survey in September 2001 found that while 79% of UK account holders have experienced 'frustrating' problems with their bank, only 26% have switched banks. A further 14% would like to switch but see it as being 'too much hassle'. This means that in many cases e-banking web sites are serving a captive audience. Predictably, this becomes very clear if we look at some of the problems that occur: • Belligerent security model. Most e-banking sites I have come across equate inconvenience with security: three or four login screens are not uncommon, yet most of the information requested is in the public domain. I have not yet seen an e-banking site that makes use of stronger security based on certificates or two-factor authentication. Either would be more secure and easier to use, although there are compatibility problems with certificates on some older brows-ers. To add insult to injury, most of the sites with difficult login procedures require full login even if all that is wanted is account balances. • Aggressive navigation. Some Jurassic e-banking sites have bizarre navigation schemes that attempt to disable the browser back button. Unfortunately, absent-minded use of the back-space key by intrepid users spoils this plan and the web site responds with considerable ferocity , typically by closing the browser. (Prehistoric rules of usability dictate that these are normally the sites with the most tortuous login.) • Precambrian design philosophy. While there are higher forms of e-banking that support finance packages such …","PeriodicalId":7070,"journal":{"name":"ACM Sigchi Bulletin","volume":"8 1","pages":"7 - 7"},"PeriodicalIF":0.0,"publicationDate":"2002-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"74304262","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Toby and Tony were the sons of a farmer. They lived in a small town near the mountain. Only one village lay closer to the mountain and it was about 20 miles away down a long straight road. Toby had a sports car and would demonstrate its speed driving down the road to the mountain at 130 mph (when the speed traps allowed). Tony drove the farm tractor, a respectable 25 mph on a good day. Toby, of course, did not take his car onto the fields.
{"title":"Real men do it generously","authors":"A. Dix","doi":"10.1145/568190.568198","DOIUrl":"https://doi.org/10.1145/568190.568198","url":null,"abstract":"Toby and Tony were the sons of a farmer. They lived in a small town near the mountain. Only one village lay closer to the mountain and it was about 20 miles away down a long straight road. Toby had a sports car and would demonstrate its speed driving down the road to the mountain at 130 mph (when the speed traps allowed). Tony drove the farm tractor, a respectable 25 mph on a good day. Toby, of course, did not take his car onto the fields.","PeriodicalId":7070,"journal":{"name":"ACM Sigchi Bulletin","volume":"61 1","pages":"6 - 6"},"PeriodicalIF":0.0,"publicationDate":"2002-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"84673498","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
'No one has ever asked me that before'. What was I asking? Well it was quite simple really. On Mon-day I had bought some flower pots and compost at the garden centre, and arranged for them to be delivered on Friday. Fine, that's part of the service they offer. But what I had done then was to go back a few days later and buy some more stuff, chairs this time, and ask to include them in the delivery that was still waiting to happen on Friday. This was not part of the model of their service. If I had just arranged a separate delivery of that second load of stuff that would have been fine, but I would have paid for the extra delivery and they might have dispatched it as a separate delivery. Merging it with the first delivery would save me money, make their delivery process more efficient, and it could also benefit their sales since being able to add more to my impending delivery is likely to entice me to buy more big, heavy stuff. As it was, although no one had asked such a thing before, it was a simple matter to dig out the old order and add the new things to it with a pen and then put the things in the holding shed with the other stuff. But the key thing was that this was an informal solution to the problem; Mike had to get Frank on the phone and they sorted it out between them, it was possible to grab a pen and add a few more things to the delivery schedule etc. With real-world processes like this you can do that, when the organisation gets bigger and when things get more rigour-ously set in processes it becomes more difficult, and no where is this more apparent than when a process is automated by computers. I recently had problems with the acceptance of my credit card for payment because the system would only approve the transaction if the credit card details matched those in the database and if the address details also matched. This meant that the person I was speaking to filled the details in and then pressed on a button to make the system try and match them. It then came back with a no or a yes. As my address is a bit vague and as the operator …
{"title":"Modelling a process","authors":"Lon Barfield","doi":"10.1145/568190.568212","DOIUrl":"https://doi.org/10.1145/568190.568212","url":null,"abstract":"'No one has ever asked me that before'. What was I asking? Well it was quite simple really. On Mon-day I had bought some flower pots and compost at the garden centre, and arranged for them to be delivered on Friday. Fine, that's part of the service they offer. But what I had done then was to go back a few days later and buy some more stuff, chairs this time, and ask to include them in the delivery that was still waiting to happen on Friday. This was not part of the model of their service. If I had just arranged a separate delivery of that second load of stuff that would have been fine, but I would have paid for the extra delivery and they might have dispatched it as a separate delivery. Merging it with the first delivery would save me money, make their delivery process more efficient, and it could also benefit their sales since being able to add more to my impending delivery is likely to entice me to buy more big, heavy stuff. As it was, although no one had asked such a thing before, it was a simple matter to dig out the old order and add the new things to it with a pen and then put the things in the holding shed with the other stuff. But the key thing was that this was an informal solution to the problem; Mike had to get Frank on the phone and they sorted it out between them, it was possible to grab a pen and add a few more things to the delivery schedule etc. With real-world processes like this you can do that, when the organisation gets bigger and when things get more rigour-ously set in processes it becomes more difficult, and no where is this more apparent than when a process is automated by computers. I recently had problems with the acceptance of my credit card for payment because the system would only approve the transaction if the credit card details matched those in the database and if the address details also matched. This meant that the person I was speaking to filled the details in and then pressed on a button to make the system try and match them. It then came back with a no or a yes. As my address is a bit vague and as the operator …","PeriodicalId":7070,"journal":{"name":"ACM Sigchi Bulletin","volume":"92 6 1","pages":"15 - 15"},"PeriodicalIF":0.0,"publicationDate":"2002-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"89456733","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
One of the main objectives of the CHI 2002 Development Consortium was to bring South African HCI practitioners and their international counterparts together to explore the challenges of creating human-centered computing products in multicultural societies. While the emphasis was mainly on the unique conditions and needs in South African society and economy, discussions also explored multicultural experiences common among developing nations like South Africa, Brazil and India.
CHI 2002发展联盟的主要目标之一是将南非的HCI从业者和他们的国际同行聚集在一起，探讨在多元文化社会中创造以人为中心的计算产品的挑战。在强调南非社会和经济的独特条件和需求的同时，也探讨了南非、巴西和印度等发展中国家共同的多元文化经验。
{"title":"CHI 2002 development consortium","authors":"J. Hugo, G. Marsden, M. Walton","doi":"10.1145/568190.568194","DOIUrl":"https://doi.org/10.1145/568190.568194","url":null,"abstract":"One of the main objectives of the CHI 2002 Development Consortium was to bring South African HCI practitioners and their international counterparts together to explore the challenges of creating human-centered computing products in multicultural societies. While the emphasis was mainly on the unique conditions and needs in South African society and economy, discussions also explored multicultural experiences common among developing nations like South Africa, Brazil and India.","PeriodicalId":7070,"journal":{"name":"ACM Sigchi Bulletin","volume":"314 1","pages":"4 - ff"},"PeriodicalIF":0.0,"publicationDate":"2002-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"77414432","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Rosson and Carroll have written the graduate textbook on the design of usable computer interfaces that I dreamed of writing, but had neither the background nor the energy to accomplish. They have brought together relevant research (much of which they produced) and practice into one volume in a very effective way. In that regard, it is gratifying as an instructor to see how they not only discuss principles (based in research), but demonstrate how those principles can be put into practice to produce usable products. There are several excellent features that are carried throughout most of the book. Perhaps the most prominent is the scenario-based approach, on which they have had so much influence over the years. Another feature, an important one from a pedagogical perspective is an example of a real development project, a virtual high school science fair. The authors introduce it in the first chapter and carry it though the remainder of the book, devoting several pages at the end of each chapter to demonstrating how the principles and processes discussed were used in developing the virtual science fair. At least once during each meeting with my interface design course, I find myself discussing one of the many tradeoffs that are manifest during the design process. Thus, I was delighted to find that Rosson and Carrol introduce that notion in the first chapter and then liberally sprinkle tradeoffs throughout the remaining chapters. The authors introduce the scenario-based approach in the first chapter. They define scenarios in general, and discuss their advantages for grounding the actual use of software systems in tasks that potential users need to perform. In chapter two (Requirements Analysis), the authors discuss such issues as identifying various groups of stake-holders, analyzing the relevant characteristics, the context, and the work practices of potential users. Here they also introduce the problem scenario, which tells a story of current practice and attempts to highlight aspects of stakeholders that have implications for design. The topic of chapter three is activity design, which has the goal of specifying system functionality. Here the authors elaborate problem scenarios into activity scenarios , which emphasize what technology can bring to the problem domain, without yet getting into details regarding the specific interface or interactions that will support those activities. In chapter four, Rosson and Carroll review basic principles of visualization, perception, and interpretation. In this context they also elaborate activity scenarios into …
{"title":"Review of","authors":"L. Wood","doi":"10.1145/568190.568210","DOIUrl":"https://doi.org/10.1145/568190.568210","url":null,"abstract":"Rosson and Carroll have written the graduate textbook on the design of usable computer interfaces that I dreamed of writing, but had neither the background nor the energy to accomplish. They have brought together relevant research (much of which they produced) and practice into one volume in a very effective way. In that regard, it is gratifying as an instructor to see how they not only discuss principles (based in research), but demonstrate how those principles can be put into practice to produce usable products. There are several excellent features that are carried throughout most of the book. Perhaps the most prominent is the scenario-based approach, on which they have had so much influence over the years. Another feature, an important one from a pedagogical perspective is an example of a real development project, a virtual high school science fair. The authors introduce it in the first chapter and carry it though the remainder of the book, devoting several pages at the end of each chapter to demonstrating how the principles and processes discussed were used in developing the virtual science fair. At least once during each meeting with my interface design course, I find myself discussing one of the many tradeoffs that are manifest during the design process. Thus, I was delighted to find that Rosson and Carrol introduce that notion in the first chapter and then liberally sprinkle tradeoffs throughout the remaining chapters. The authors introduce the scenario-based approach in the first chapter. They define scenarios in general, and discuss their advantages for grounding the actual use of software systems in tasks that potential users need to perform. In chapter two (Requirements Analysis), the authors discuss such issues as identifying various groups of stake-holders, analyzing the relevant characteristics, the context, and the work practices of potential users. Here they also introduce the problem scenario, which tells a story of current practice and attempts to highlight aspects of stakeholders that have implications for design. The topic of chapter three is activity design, which has the goal of specifying system functionality. Here the authors elaborate problem scenarios into activity scenarios , which emphasize what technology can bring to the problem domain, without yet getting into details regarding the specific interface or interactions that will support those activities. In chapter four, Rosson and Carroll review basic principles of visualization, perception, and interpretation. In this context they also elaborate activity scenarios into …","PeriodicalId":7070,"journal":{"name":"ACM Sigchi Bulletin","volume":"67 1","pages":"12 - 12"},"PeriodicalIF":0.0,"publicationDate":"2002-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"73577818","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：