IBM needs a way for its employees to interact beyond the teleconference and to connect across geographies. We've accepted that meetings are an inescapable part of our corporate culture, but we also recognize that shorter, focused meetings will make us more productive. Internal virtual worlds give "I've Been Meeting" (as some affectionately call us) the opportunity to improve on meetings themselves, and experiment with more interactive and effective approaches to them.
Perhaps the most interesting thing we've seen in this environment is that people can't multi-task easily while in a virtual meeting, if they don't give it their full attention they can literally get lost. Conversely, attendees have a shortened attention span, so meetings need to stay on topic and valuable.
As metaverse is an experimental system, the boulder was merely created as part of our development work. We left the boulder in there figuring if we gave users a ball, they'd play with it. We wanted to encourage their exploration of this medium and thereby discover value. Right now, we're entirely focused on getting to the right questions about internal virtual worlds, rather than setting out to immediately seize upon business value.
So far, the boulder has primarily been used to teach employees how to interact and cooperate in the world, but we've been surprised how much it acts as a focal point for people in-world. People are drawn together to play with it, without any direct benefit or goal.
IBM's had a whole bunch of releases on Carbon Nanotubes, most recently there was the one about a solid-state light emitter, and in may 2002 we made CNT transistors that out performed the Si ones.
The IBM releases/etc on Carbon Nanotubes can all be found here.
Doh - that's what happens when late nights get mixed with a background in biology. Yes, Phoneme, not phenome (thank you to the ed. who corrected that).
I know it's hard to find corporate research these days, but at least here at IBM we still do plenty of it. Research internships/summer coop positions/etc are a bit different than the usual port-this, document that type work - there are opportunities to contribute to more cutting edge stuff. However, most big companies have their internships posted up by Jan 1 each year, so the spaces are already getting scarce by mid-March.
Corporations often find themselves dealing with the issue of how to make inherently accessibility-unfriendly content accessible. For example, information about visual user interfaces (which would likely contain screen shots of proposed interfaces) is difficult to convey to vision-impaired users; it may not even be relevant to them. How would you advise approaching this issue?
You missed a line: while I agree that there are too many cases of webpage developers stressing design over content, there are other cases where the design augments the content
thanks for the link: Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media... [tables often coded poorly]... To minimize these problems, authors should use style sheets to control layout rather than tables.
In addition, 70% of my NS users are on 4.x or below, which poorly handles CSS. IMHO, the Web is not for presenting data in the most textish format possible (though Nielsen won't agree with me ^_^), but to get a message to the users, all users, and not lose details because of variations in the browser.
Not necessarily - while I agree that there are too many cases of webpage developers stressing design over content, there are other cases where the design augments the content. Take, for example, a simple table. In html, the table has long since ceased to be merely a mechanism to contain spreadsheet data and instead morphed into design control code. However, it extends beyond the "here's a page with a masthead, nav, footer, and we've built it all into a table" but rather "this content needs to appear alongside that other content with thin vertical lines of different, meaningful, colors." Netscape (/Mozilla) and IE handle tables very differently, this was more evident in early versions where Netscape would chew on big tables for several minutes while IE rendered them in several seconds (but it was integrated with the OS! I know, I know...), a more recent fluke is that NS can have trouble with 1 pixel high table cells. As a result, it can be difficult to effect more complicated design-content combos without using images (which have their own accessibility problems) because of the differences between browsers. IMHO, the key isn't to get hung up on the details of how one browser will behave versus another but simply to pick a solution that gets my content to the user in the most meaningful way. Good web design requires adjusting content to a layout that will adapt easily to browser limitations (especially when using the lowest-common-denominator approach), which is why it is important for browsers to move toward standards that require consistent display behavior.
And by Lion's share, we're talking 80%+. However, that doesn't mean web developers can say "it looks good in IE and OK in mozilla," so it's 'mostly-good' and thus sufficient. Pages need to be designed for the greatest possible accessibility and that includes all of the major browsers, earlier versions, and screen reader software (getting back to the 508 comment).
All too often i've been seeing trade-ins on design/coding_ease for standards compliance (particularly with fixed font sizes in css), better standards (WaSP) with more universal browser adherence to such standards.
Last comment (then i'll shaddap), the different browser interpretations of a particular piece of HTML has always been a problem and, though better, it is still an issue. Though this probably exists already, a good website identifying the differences on a case by case would be useful to the developer community. In addition, such a site could recommend lowest-common-denominator solutions and WaSP standards at the same time.
It will definitely be different, and it's got some cool advantages. The announcement from IBM Research labs in Zurich talk about a data storage density 20 times that of today's best magnetic storage. Briefly, tiny V shaped heads make holes 10 nanometers wide in a plastic film - there are a number of interesting stats and potential applications described in the article, as well as some animations (1,2). The story is also reported in The NY Times and C|Net.
Just cause it's on topic, and helps explain the "autonomous computing" reference in the intro to this thread...
IBM's Autonomic Computing site: http://www.research.ibm.com/autonomic
Heh, more interesting than that - there's no cookie sent in my request packets. (I just reinitialized the packet log and ran the test again, then checked every packet transferred to be sure). Even tried (unsuccessfully) to pick up a cookie on netscape.com, no dice.
---
For those still following along, a cookie at the end of the HTTP request packet would have been an additional line:
Cookie: (1K worth of cookie data from the browser)
There's also the occassional
If-Modified-Since: Dow, DD Mmm YYYY hh:mm:ss TMZ
Oh well. My missing ns cookie: Another unexplained phenomenon left trailing on a beyond-the-homepage/.
So i was curious about what was actually being sent to AOL when one did a google search from the netscape bar. Here's the HTTP request:
GET/fwd/lksidus_gg/http://www.google.com/search?q=tes tpriv9&sourceid=mozilla-search HTTP/1.1
Host: info.netscape.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1
Accept-Language: en-us
Accept-Encoding: gzip,deflate,compress,identity
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
There's also the usual data stuffed in the TCPIP header, such as IP address. There are some additional g'day requests to info.netscape.com which might contain unique ID information and would also be matched to TCPIP header info, but if there are any explicit UIDs in this packet i must be missing em.
The developers probably had a good reason for setting things up this way: If the URL for a search engine changed, they could always update their fwd script and prevent users from going to a broken page. Unfortunately, this means data gets sent to a site other than that intended by the user. A much better way of doing this would be for the client to check for updates to the search URLs and store them locally.
While i'm not privy to all the cool stuff they've been doing on this project, there was a hint dropped about possible operating systems: "In addition, it can run multiple operating systems that share the same data"
Now lets see, what other OS is IBM pushing these days?
More specifically, the IBM "Meta Pad" Release specifies that the project code name is Meta Pad, no claims of a product TM (software, hardware, or otherwise).
Personally? I think this is a whole lot cooler than any notepad alternative (besides, i use "EditPad" heheh).
IBM Research has some more info about this direction in pervasive devices. The article above links to the WatchPad, aka Linux on a watch. There's also some info on the IBM Almaden Research Center's CS homepage and a link to an Infoworld article about IBM's Digital Jewelry.
Personally, i wonder if those Disk-on-Key(chain) devices count as jewelry... Either way i'm more than happy to see computing power leave the desktop/laptop-bag and migrate into more people-compatible interfaces.
Slashdot Mirror
IBM needs a way for its employees to interact beyond the teleconference and to connect across geographies. We've accepted that meetings are an inescapable part of our corporate culture, but we also recognize that shorter, focused meetings will make us more productive. Internal virtual worlds give "I've Been Meeting" (as some affectionately call us) the opportunity to improve on meetings themselves, and experiment with more interactive and effective approaches to them.
Perhaps the most interesting thing we've seen in this environment is that people can't multi-task easily while in a virtual meeting, if they don't give it their full attention they can literally get lost. Conversely, attendees have a shortened attention span, so meetings need to stay on topic and valuable.
As metaverse is an experimental system, the boulder was merely created as part of our development work. We left the boulder in there figuring if we gave users a ball, they'd play with it. We wanted to encourage their exploration of this medium and thereby discover value. Right now, we're entirely focused on getting to the right questions about internal virtual worlds, rather than setting out to immediately seize upon business value.
So far, the boulder has primarily been used to teach employees how to interact and cooperate in the world, but we've been surprised how much it acts as a focal point for people in-world. People are drawn together to play with it, without any direct benefit or goal.
Here's the IBM press release (w/ pics) (check out the animation from that page)
Here's a whole page of pics (red, yellow and blue - sorry, no green)
Here's the project page from the researchers
IBM's had a whole bunch of releases on Carbon Nanotubes, most recently there was the one about a solid-state light emitter, and in may 2002 we made CNT transistors that out performed the Si ones.
The IBM releases/etc on Carbon Nanotubes can all be found here.
Here's the detailed info on all this:
IBM Research Light Emitting Carbon Nanotube news release
There's also an animation, but the pictures in the release are easier to follow.
This all sounds a lot like what IBM proposed over a year ago.
See the Meta Pad announcement (Feb 2002) or read about it on Slashdot
Doh - that's what happens when late nights get mixed with a background in biology.
Yes, Phoneme, not phenome (thank you to the ed. who corrected that).
Why Hokkus and not a long renga? Now we have to remember each individual element's poem instead of one long verse.
I know it's hard to find corporate research these days, but at least here at IBM we still do plenty of it. Research internships/summer coop positions/etc are a bit different than the usual port-this, document that type work - there are opportunities to contribute to more cutting edge stuff. However, most big companies have their internships posted up by Jan 1 each year, so the spaces are already getting scarce by mid-March.
IBM Research still has a number of graduate and undergraduate internships posted on the site.
Just two cents about research overseas (particularly china, japan, and india, which you called out):
http://www.research.ibm.com/worldwide/
Corporations often find themselves dealing with the issue of how to make inherently accessibility-unfriendly content accessible. For example, information about visual user interfaces (which would likely contain screen shots of proposed interfaces) is difficult to convey to vision-impaired users; it may not even be relevant to them. How would you advise approaching this issue?
You missed a line:
... [tables often coded poorly] ... To minimize these problems, authors should use style sheets to control layout rather than tables.
while I agree that there are too many cases of webpage developers stressing design over content, there are other cases where the design augments the content
thanks for the link:
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media
In addition, 70% of my NS users are on 4.x or below, which poorly handles CSS. IMHO, the Web is not for presenting data in the most textish format possible (though Nielsen won't agree with me ^_^), but to get a message to the users, all users, and not lose details because of variations in the browser.
Not necessarily - while I agree that there are too many cases of webpage developers stressing design over content, there are other cases where the design augments the content. Take, for example, a simple table. In html, the table has long since ceased to be merely a mechanism to contain spreadsheet data and instead morphed into design control code. However, it extends beyond the "here's a page with a masthead, nav, footer, and we've built it all into a table" but rather "this content needs to appear alongside that other content with thin vertical lines of different, meaningful, colors." Netscape (/Mozilla) and IE handle tables very differently, this was more evident in early versions where Netscape would chew on big tables for several minutes while IE rendered them in several seconds (but it was integrated with the OS! I know, I know...), a more recent fluke is that NS can have trouble with 1 pixel high table cells. As a result, it can be difficult to effect more complicated design-content combos without using images (which have their own accessibility problems) because of the differences between browsers. IMHO, the key isn't to get hung up on the details of how one browser will behave versus another but simply to pick a solution that gets my content to the user in the most meaningful way. Good web design requires adjusting content to a layout that will adapt easily to browser limitations (especially when using the lowest-common-denominator approach), which is why it is important for browsers to move toward standards that require consistent display behavior.
And by Lion's share, we're talking 80%+. However, that doesn't mean web developers can say "it looks good in IE and OK in mozilla," so it's 'mostly-good' and thus sufficient. Pages need to be designed for the greatest possible accessibility and that includes all of the major browsers, earlier versions, and screen reader software (getting back to the 508 comment).
All too often i've been seeing trade-ins on design/coding_ease for standards compliance (particularly with fixed font sizes in css), better standards (WaSP) with more universal browser adherence to such standards.
Last comment (then i'll shaddap), the different browser interpretations of a particular piece of HTML has always been a problem and, though better, it is still an issue. Though this probably exists already, a good website identifying the differences on a case by case would be useful to the developer community. In addition, such a site could recommend lowest-common-denominator solutions and WaSP standards at the same time.
It will definitely be different, and it's got some cool advantages. The announcement from IBM Research labs in Zurich talk about a data storage density 20 times that of today's best magnetic storage. Briefly, tiny V shaped heads make holes 10 nanometers wide in a plastic film - there are a number of interesting stats and potential applications described in the article, as well as some animations (1,2). The story is also reported in The NY Times and C|Net.
For those looking for this story, it is posted on the IBM Research website. There are also news stories on the NY Times and C|Net.
Just cause it's on topic, and helps explain the "autonomous computing" reference in the intro to this thread...
IBM's Autonomic Computing site: http://www.research.ibm.com/autonomic
Heh, more interesting than that - there's no cookie sent in my request packets. (I just reinitialized the packet log and ran the test again, then checked every packet transferred to be sure). Even tried (unsuccessfully) to pick up a cookie on netscape.com, no dice.
/.
---
For those still following along, a cookie at the end of the HTTP request packet would have been an additional line:
Cookie: (1K worth of cookie data from the browser)
There's also the occassional
If-Modified-Since: Dow, DD Mmm YYYY hh:mm:ss TMZ
Oh well. My missing ns cookie: Another unexplained phenomenon left trailing on a beyond-the-homepage
So i was curious about what was actually being sent to AOL when one did a google search from the netscape bar. Here's the HTTP request: /fwd/lksidus_gg/http://www.google.com/search?q=tes tpriv9&sourceid=mozilla-search HTTP/1.1
GET
Host: info.netscape.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1
Accept-Language: en-us
Accept-Encoding: gzip,deflate,compress,identity
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
There's also the usual data stuffed in the TCPIP header, such as IP address. There are some additional g'day requests to info.netscape.com which might contain unique ID information and would also be matched to TCPIP header info, but if there are any explicit UIDs in this packet i must be missing em.
The developers probably had a good reason for setting things up this way: If the URL for a search engine changed, they could always update their fwd script and prevent users from going to a broken page. Unfortunately, this means data gets sent to a site other than that intended by the user. A much better way of doing this would be for the client to check for updates to the search URLs and store them locally.
Just some thoughts.
(*sigh*) Just cause this thread keeps re-appearing: The prototypes have a 10GB (Gigabyte) drive in them.
While i'm not privy to all the cool stuff they've been doing on this project, there was a hint dropped about possible operating systems:
"In addition, it can run multiple operating systems that share the same data"
Now lets see, what other OS is IBM pushing these days?
More specifically, the IBM "Meta Pad" Release specifies that the project code name is Meta Pad, no claims of a product TM (software, hardware, or otherwise).
Personally? I think this is a whole lot cooler than any notepad alternative (besides, i use "EditPad" heheh).
IBM Research has some more info about this direction in pervasive devices. The article above links to the WatchPad, aka Linux on a watch. There's also some info on the IBM Almaden Research Center's CS homepage and a link to an Infoworld article about IBM's Digital Jewelry.
Personally, i wonder if those Disk-on-Key(chain) devices count as jewelry... Either way i'm more than happy to see computing power leave the desktop/laptop-bag and migrate into more people-compatible interfaces.
Hmm, yah, 42 indeed. It took ~30 years (early 90's) for MEMs to start appearing but it's 42 years (heh, as of tomorrow) since Feynman's speech.