Usually, someone should say "hey, are we following the RFC for the protocol here?"
Usually, someone should say "isn't hardcoding one single IP address for a service a bad design idea?"
None of these things apparently happened. It may not show up in "testing" (hey, everything worked fine) but in quality assurance, they should be checking their code for anomalies.
As for the font issue - well, how're you going to resize the text in some site's graphics? Far too many designers decide that their site would look *great* if they use a teeeeeeny font rendered and anti-aliased into a lovely graphic. Can't be resized. Visually-imparied folks are boned. All the IE trickery in the world isn't going to help that too much.
XHTML and CSS aren't really new - CSS1 has been around for several years now, just as long as the more common versions of HTML. And CSS really *doesn't* do the same thing as a font tag. It's kinda like saying "Why should I use C++? It does the same thing as PL/1." While you may love your font tags and nested tables, frankly CSS offers you a lot more design flexibility, helps separate design from content (that way your authors don't screw up your design be accidentally deleting a font tag), allows you to update an entire website at a crack, etc etc. And browser shave been supporting it (albeit some like NS 4 not exactly well) for years. It always surprises me how much some designers struggle against it - it's got so much of what they've been asking for in HTML for years - pixel-level positioning, font control, type spacing, layering, floats, etc etc. Plus you can use multiple targets easily in CSS - one CSS for web, one for voice readers, one for print...it's remarkably handy.
XHTML is pretty much the same as HTML. It's just more strictly codified. Close your tags. Keep your capitalization consistant. Don't try and close nested tags out of order. I fail to see how enforcing proper use of code is a bad thing. If you write good html already, then it probably comes pretty close to validating to XHTML already.
And the final question - most if not all screen readers *can* understand tables just fine. But they're really best for tabular data. Tables used for design purposes alone end up being pretty much irrelevant to a screen-reader at best (nothing lost there); at worst they present the content in a flow that's confusing not to the machine but to the person trying to figure out why paragraph 2 comes before the title. Use CSS layers and you can move stuff around in any visual order, but still keep the logical order of the information preserved.
I'm assuming you stumbled across my personal and/or band site. Yeah, that's a mess. I'm working on it. I'm still in the process of upgrading it from a terribly old-and-out-of date design that didn't take much of that into account.
I tend to be a little more exacting when people are paying me to do this stuff.
And I'm one of those people. Far too many sites were marred in the late 90's - and far too many are marred now - by dull sonic wallpaper that serves no purpose other than slowing downloads. Never serves a purpose, always startles the hell out of me when I'm listening to something else and my speakers start blaring some boring floaty synth loops, and...well, it's just annoying.
Nothing wrong with nested tables, although so many, many many people abuse them horribly. Do you really need a separate, 1-cell table to make a blue border? Not really. A few nested tables, fine. But in one of my previous employments I had to deal with a site that had *15* levels of table nesting for no reason other than making that box orange and that box yellow. Madness, I tell you, madness.
In the US, it's Section508 of the Americans with Disabilities Act.
EVERYBODY and their brother gets up-in-arms about having the government legislate their web design. Nobody bothers to read this stuff.
So here're my bullet points:
1) s508 compliance it's only required if you're a federal government agency or contractor, and even then there are some exceptions.
2) C'mon people, it's really *not* that hard to comply. Got ALT tags? You're halfway there. Lose the 7 layers of nested tables and nobody'll complain.
3) it's 2003 now - the era of overdesigned websites ended with the.com crash. The vast market of consumers don't care if a site is animated to holy heck and streams ambient music anymore - It's not going to sell your product or content any better anymore than a well-designed but accessible/usable site.
4) A site doesn't have to be ugly and nonvisual to be accessible. Proper use of CSS can give you a fantastic site that degrades nicely into a screen-reader, brailler, etc.
5) Not every disabled person involved is a blind, deaf quadrapelegic. Some are just nearsighted folks who want to set the font size something above the Arial-submicroscopic-pt that eagle-eyed designers often use. Why not let them?
6) There are several hundred million users worldwide who consider themselves disabled in some way. If you're selling things, would you shut your door to 200,000,000 potential customers because it's inconvenient for you to serve them?
7) A plus to an accessible website is that it will almost always degrade well to other browsers - especially things like wireless devices and phones. Make your site accessible, and you've gone a long way towards making it mobile as well.
8) Jeffrey Zeldman's new book "Designing with Web Standards" is an excellent resource. He demonstrates how to use current standards like XHTML, CSS to create websites that are complaint with standards, work well on the vast majority of browsers, are attractive, usable, and accessible. Definitely worth checking out, as is his website, www.zeldman.com.
Accessibility shouldn't be considered an incovnenience - it's just good practice.
I discovered, while running a few different Java apps (SunOne, Eclipse, and a java image viewer I was playing with) that DirectDraw (with some video cards, not all, which is what makes this a really nasty bug) conflicts with the java2d package. Conflicts to the point of causing video to freeze or other nasty little bugs. For instance, you can't quit out of a java app. It just hangs there and eventually your system freezes.
however, running dxdiag.exe and disabling directdraw before running a java app seems to have fixed the problem.
Now more to your lack of a point. Java runs GREAT on Windows 95-XP.
Well, provided you don't have directDraw enabled or aren't using the java2d package...
(lemme tell you how painful it was to discover *that* little incompatibility...)
The big thing missing? Enterprise integration. Slapping a PHP app in a business running on Windows with a Wintel IT shop is going to be problematic. Trust me, I've tried this.
First off - you've got issues with migrating your programmers. ASP.NET has essentially an event-driven model, which is lacking from ASP, PHP, JSP, and CFM.
This doesn't seem like a big deal, right?
Well, imagine you've got a platoon of VB programmers on your staff, who've written apps with an event-driven model for 15 years. I've seen this, they tend to write awful, awful code in a request-response model. Drop them in front of VB.NET and suddenly it works pretty much the same. Repurpose your programmers!
Hey, I didn't say it always worked.
There're additional issues with desktop software integration. With remoting and web services, it's pretty easy to write a windows desktop app and a web app that do the same thing, and even share code. PHP lacks the ability to do that.
Again, I didn't say this was always a great idea, but if you're an IT manager with a dozen VB programmers onstaff...
Another problem PHP faces is one of support. When your windows admin has trouble installing PHP, who can they call for definitive answers? Who can they open a trouble ticket with? Well, okay, Zend, but most people aren't aware of that, and most IT managers know for certain that there's a Microsoft Licensed Support Partner just off the interstate, and 35 MS-partner consultancies they can call. It's a stupid reason to most of us, but to an IT manager, that's a very real concern.
Most people forget that ASP.NET is just a single component of the.NET strategy. Unfortunately thanks to MS's wonderful marketing department, it's become the most visible and is associated with the whole thing. There's.NET remoting,.NET Web Services,.NET Windows forms, etc. The big deal MS wanted everyone to see is that they're all interrelated and thus enterprise-ready. Problem is, nobody does, and continues to use ASP.NET as the only part of it. And in a mixed environment of windows apps, ASP.NET, ASP, dll hell, etc...well, of course it gets a bad rap. It was naive of MS to think that users would upgrade everything simultaneously, and it probably hurt their adoption.
It also didn't help that they branded every server, software package, and component something.NET regardless of what it was. Really didn't help their argument much.
I've had to write apps in both PHP and C#.NET. The PHP apps came together much faster, but...damn, ADO.NET has some sweetness there. No server-proprietary calls, everything's native in XML if you want to manipulate data that way, and web services, when they work, are pretty cool and super-easy to write.
Just wanna second the recommendation for the Kolb book (or any of his books. "Blind Watchers of the Sky" is good too). Rocky Kolb has a great way of explaining things so that it's interesting for everyone.
Well, this is entirely dependent on the quality of the ADCs in the guitar. Yeah, analog gear is limited by the CD format, but if you've got the right gear for doing the analog-to-digital conversion, you lose a lot less. This is why a lot of pro systems are sampling at 96-bits and 192khz - it's absurdly high resolution, far beyond the ear, but it's much nicer if you're going to be doing any processing on the signal. Your fidelity loss is minimized.
If you're working an analog-to-digital converter into a guitar that runs off a 9-volt, chances are it's going to be pretty craptacular. They say MaGIC is capable of 32-bit/192khz audio but they don't say that that's what the guitar is using. What you're more than likely to get out the back end is a thin and very digital sound. And if it's only CD quality, then what's the point? You're much better off getting a good mic'ed amp, getting some decent character into the sound (I don't care what anybody says about analog hardware - it's not the "warmth" of the sound that's the payoff, it's the odd little extra overtones, detunings etc that give you a good sound) and then run that into a really good ADC. Your end product will have much more going for it.
There's also questions about the internal signal path of the guitar - how hard is it going to be to wire in a good set of pickups? Say you want to swap in a set of EMG's or Seymour Duncans for a different tonal characteristic - can you do it with a soldering iron and some tape like you can now, or will you need a degree in electronics and a good logic probe?
The Hex Pickup is nothing new. You can get 'em for bass now, you can get 'em for guitar, and I've even seen comparable systems on violin. Sending on separate channels isn't a big deal. You can do cool stuff with it right now in terms of transposition, etc. The ARP Avatar guitar synth (the beast that killed ARP corporation) could do that back in 1978. That was synthesis, but even with the more recent hex-pickuped modelling effects units (Roland COSM for example) there's still some latency. It's not bad if you're just effecting a signal. It's if you want to manipulate the pitch, timing, attack or whatnot that the trouble occurs. The problem has always been one of tracking; pitch isolation is pretty slow no matter what signal format you use - there's elements of crosstalk from other strings, there's overtones to worry about, pitch "deformaties" from picking, issues with bending and portamento etc etc.
And the final problem is this - how well is Gibson going to provide this format to other vendors? Will you be able to get a MaGIC Fender? Or buy a synthesizer that speaks MaGIC? Will this have significant advantages over existing digital audio and sync formats? Will you be locked into Gibson gear? Gibson's track record for technology has been awful - they pretty much killed the ever-promising OMS MIDI-routing system when they bought Opcode (right when the PC version had started to mature) and refused to release the sourcecode to developers despite a large petition. Really, the last thing the music world needs is a closed format for recording, especially one limited to Gibson-and-affiliates.
This is the fun of non-linear dynamics, commonly called "chaos theory."
Weather is the classic case of sensitive dependence on initial conditions. Butterflies in China and all that.
As nice an idea as it would be to just say "no bad weather" we could really, really screw things up. "No bad weather now! Yay! Whoops, we just flooded Oregon!"
Part of the problem with this is designer's environment - they've all got excellent monitors and great eyesight. Arial 8pt looks fine and is all hip when you're used to that sort of thing.
Stick 'em on a crappy laptop and give them the slight nearsightedness the rest of us have, suddenly I think everything would be at least 12-point again.
This is one of the theological pitfalls of monotheism. If you have an omnipotent god, you get all sorts of fun little paradoxes.
i.e. can God make a pie so big that even He couldn't eat it?
Reagrdless of the answer, you're left with an non-omnipotent god, which goes against the omnipotent monotheistic ideal.
Many philosophers have spent a lot of tiem rationalizing this out. Otehres have spent a lot of time using this to prove that God doesn't exist.
Polytheisms don't fall victim to this, since rarely do they ever have or need an all-powerful god-figure. Gods/goddesses with specific domains don't need to be all-powerful to get their jobs done. Of course, polytheism has other theological problems.
Theological philsophy is interesting to study. Brain-hurting sometimes, but fun.
I wouldn't really want to be either gaming or running 3d apps on a laptop anyway. To do anything really serious you need non-battery-powerable hardware anyway - good monitor for graphics, external audio interface for studio sound (not counting PCMCIA interfaces, but the latency of those bugs me), satellite dish for remote-controlling Mars probes...
I've got a SmartStep 250 myself, and I knew about speedstepping, and I really didn't care. I've owned 4 laptops now and I think I've had them all on battery for a total of 10 hours. If it's running at 1.1gHz and all I'm doing is email, it's plenty fast enough. If VS.NET takes an extra minute to compile (hey, stop laughing, it pays the bills) that's just that much more time to drink coffee and read Slashdot.
I've seen a lot of peole complaining about the guv'ment legislating their freedom of website-expression with section 508.
Well, there seems to be a bit of misunderstanding, and it would've been better had the reviewer mentioned this.
Section508 applies primarily to governmental websites. So if you're a.gov or a.state.us then it's likely you need to comply to section508. If you're a federal or state contractor you may have to comply.
If you're not one of those things, do whatever you want.
However, it may still be in your best interests to at least consider accessibility. You may not necessarily comply with all the W3C priority 1,2, and 3 standards but a few of them isn't going to hurt, and are generally common sense. There's a huge market out there for the disabled - if you ran a brick-n-mortar shop you wouldn't turn away $175billion worth of your customers, so why do it on the web?
It's not like *all* of them are blind, deaf quadraplegics. I know people who use expanded fonts just because their eyesight isn't *great* - they're still legal to drive with glasses, but reading fine print on a screen necessitates assistance. Variable font-sizing and alt tags would suddenly open your website up to a lot of people just like that.
Basically, to help make a site more accessible it doesn't require much - start with your alt tags, maybe longdesc if you're feeling generous, try not to deisgn with 7 layers of nested tables, and use relative font sizes. Most sites won't even need to be fully overhauled to accomplish this, just tweaked, and it can open up the availability to hundreds of thousands more people.
It's not about being politically correct, it's not about avoiding lawsuits, it's about doing what's best for your website and delivering your content to the widest audience.
Well, it's not so much the problem with screen readers - that's just it. How do you screen-read something that's blinking? Or screen-read a picture without any information about what it is? Or screen-read a lovely layout that is position-sensitive?
That's the issue - there are things that rely on visual cues, which just *can't* make the leap to screen-reading.
There are other problems too - screen-readers aren't the only devices used for accessibility, as the visually-handicapped aren't the only disabled people using computers.
There's a large number of issues to take into account, but frnakly none of them are too daunting to plan for. One can make a lovely and useful website that's fully s508 compliant as long as you're thinking about it in the deisgn phase.
But 45 gazillion web users, designers, and coders thing otherwise and thus, they do.
Slashdot readers/sysadmins/code jockeys are not the intended audience for the web anymore. Once, sure, now the web userbase is the masses. The users want what they want, and it's arrogant to the extreme to have a few of us dictate what that is to be.
Conversely, some users take things to the extreme - 10 non-standard fonts on a page, multiple flash animations, overdesigned pixel-specific everything...but there is a line everyone has to walk.
Usable Web Pages Do Not Have To Be Dull. Aesthetically Pleasing (in other words, "fly") Web Pages Do Not Have to Be Unusable.
Geeks need to remember that this isn't 1993 anymore and Tim Berners-Lee is no longer the only driving force for web development. Artists need to remember this isn't 1997 when a hip design got your site noticed and brought in sales.
Slashdot Mirror
Usually, there should be a code review.
Usually, someone should say "hey, are we following the RFC for the protocol here?"
Usually, someone should say "isn't hardcoding one single IP address for a service a bad design idea?"
None of these things apparently happened. It may not show up in "testing" (hey, everything worked fine) but in quality assurance, they should be checking their code for anomalies.
So /. is just a giant magic eight ball?
Ask again later.
As for the font issue - well, how're you going to resize the text in some site's graphics? Far too many designers decide that their site would look *great* if they use a teeeeeeny font rendered and anti-aliased into a lovely graphic. Can't be resized. Visually-imparied folks are boned. All the IE trickery in the world isn't going to help that too much.
XHTML and CSS aren't really new - CSS1 has been around for several years now, just as long as the more common versions of HTML. And CSS really *doesn't* do the same thing as a font tag. It's kinda like saying "Why should I use C++? It does the same thing as PL/1." While you may love your font tags and nested tables, frankly CSS offers you a lot more design flexibility, helps separate design from content (that way your authors don't screw up your design be accidentally deleting a font tag), allows you to update an entire website at a crack, etc etc. And browser shave been supporting it (albeit some like NS 4 not exactly well) for years. It always surprises me how much some designers struggle against it - it's got so much of what they've been asking for in HTML for years - pixel-level positioning, font control, type spacing, layering, floats, etc etc. Plus you can use multiple targets easily in CSS - one CSS for web, one for voice readers, one for print...it's remarkably handy.
XHTML is pretty much the same as HTML. It's just more strictly codified. Close your tags. Keep your capitalization consistant. Don't try and close nested tags out of order. I fail to see how enforcing proper use of code is a bad thing. If you write good html already, then it probably comes pretty close to validating to XHTML already.
And the final question - most if not all screen readers *can* understand tables just fine. But they're really best for tabular data. Tables used for design purposes alone end up being pretty much irrelevant to a screen-reader at best (nothing lost there); at worst they present the content in a flow that's confusing not to the machine but to the person trying to figure out why paragraph 2 comes before the title. Use CSS layers and you can move stuff around in any visual order, but still keep the logical order of the information preserved.
I'm assuming you stumbled across my personal and/or band site. Yeah, that's a mess. I'm working on it. I'm still in the process of upgrading it from a terribly old-and-out-of date design that didn't take much of that into account.
:)
I tend to be a little more exacting when people are paying me to do this stuff.
Physician, heal thyself.
And I'm one of those people. Far too many sites were marred in the late 90's - and far too many are marred now - by dull sonic wallpaper that serves no purpose other than slowing downloads. Never serves a purpose, always startles the hell out of me when I'm listening to something else and my speakers start blaring some boring floaty synth loops, and...well, it's just annoying.
Nothing wrong with nested tables, although so many, many many people abuse them horribly. Do you really need a separate, 1-cell table to make a blue border? Not really. A few nested tables, fine. But in one of my previous employments I had to deal with a site that had *15* levels of table nesting for no reason other than making that box orange and that box yellow. Madness, I tell you, madness.
In the US, it's Section508 of the Americans with Disabilities Act.
.com crash. The vast market of consumers don't care if a site is animated to holy heck and streams ambient music anymore - It's not going to sell your product or content any better anymore than a well-designed but accessible/usable site.
EVERYBODY and their brother gets up-in-arms about having the government legislate their web design. Nobody bothers to read this stuff.
So here're my bullet points:
1) s508 compliance it's only required if you're a federal government agency or contractor, and even then there are some exceptions.
2) C'mon people, it's really *not* that hard to comply. Got ALT tags? You're halfway there. Lose the 7 layers of nested tables and nobody'll complain.
3) it's 2003 now - the era of overdesigned websites ended with the
4) A site doesn't have to be ugly and nonvisual to be accessible. Proper use of CSS can give you a fantastic site that degrades nicely into a screen-reader, brailler, etc.
5) Not every disabled person involved is a blind, deaf quadrapelegic. Some are just nearsighted folks who want to set the font size something above the Arial-submicroscopic-pt that eagle-eyed designers often use. Why not let them?
6) There are several hundred million users worldwide who consider themselves disabled in some way. If you're selling things, would you shut your door to 200,000,000 potential customers because it's inconvenient for you to serve them?
7) A plus to an accessible website is that it will almost always degrade well to other browsers - especially things like wireless devices and phones. Make your site accessible, and you've gone a long way towards making it mobile as well.
8) Jeffrey Zeldman's new book "Designing with Web Standards" is an excellent resource. He demonstrates how to use current standards like XHTML, CSS to create websites that are complaint with standards, work well on the vast majority of browsers, are attractive, usable, and accessible. Definitely worth checking out, as is his website, www.zeldman.com.
Accessibility shouldn't be considered an incovnenience - it's just good practice.
I discovered, while running a few different Java apps (SunOne, Eclipse, and a java image viewer I was playing with) that DirectDraw (with some video cards, not all, which is what makes this a really nasty bug) conflicts with the java2d package. Conflicts to the point of causing video to freeze or other nasty little bugs. For instance, you can't quit out of a java app. It just hangs there and eventually your system freezes.
however, running dxdiag.exe and disabling directdraw before running a java app seems to have fixed the problem.
Now more to your lack of a point. Java runs GREAT on Windows 95-XP. Well, provided you don't have directDraw enabled or aren't using the java2d package... (lemme tell you how painful it was to discover *that* little incompatibility...)
Hey, I can get "Hello World" to compile on almost any platform.
Still having a little trouble with the OS X port, though...
The big thing missing? Enterprise integration. Slapping a PHP app in a business running on Windows with a Wintel IT shop is going to be problematic. Trust me, I've tried this.
.NET strategy. Unfortunately thanks to MS's wonderful marketing department, it's become the most visible and is associated with the whole thing. There's .NET remoting, .NET Web Services, .NET Windows forms, etc. The big deal MS wanted everyone to see is that they're all interrelated and thus enterprise-ready. Problem is, nobody does, and continues to use ASP.NET as the only part of it. And in a mixed environment of windows apps, ASP.NET, ASP, dll hell, etc...well, of course it gets a bad rap. It was naive of MS to think that users would upgrade everything simultaneously, and it probably hurt their adoption.
First off - you've got issues with migrating your programmers. ASP.NET has essentially an event-driven model, which is lacking from ASP, PHP, JSP, and CFM.
This doesn't seem like a big deal, right?
Well, imagine you've got a platoon of VB programmers on your staff, who've written apps with an event-driven model for 15 years. I've seen this, they tend to write awful, awful code in a request-response model. Drop them in front of VB.NET and suddenly it works pretty much the same. Repurpose your programmers!
Hey, I didn't say it always worked.
There're additional issues with desktop software integration. With remoting and web services, it's pretty easy to write a windows desktop app and a web app that do the same thing, and even share code. PHP lacks the ability to do that.
Again, I didn't say this was always a great idea, but if you're an IT manager with a dozen VB programmers onstaff...
Another problem PHP faces is one of support. When your windows admin has trouble installing PHP, who can they call for definitive answers? Who can they open a trouble ticket with? Well, okay, Zend, but most people aren't aware of that, and most IT managers know for certain that there's a Microsoft Licensed Support Partner just off the interstate, and 35 MS-partner consultancies they can call. It's a stupid reason to most of us, but to an IT manager, that's a very real concern.
Most people forget that ASP.NET is just a single component of the
It also didn't help that they branded every server, software package, and component something.NET regardless of what it was. Really didn't help their argument much.
I've had to write apps in both PHP and C#.NET. The PHP apps came together much faster, but...damn, ADO.NET has some sweetness there. No server-proprietary calls, everything's native in XML if you want to manipulate data that way, and web services, when they work, are pretty cool and super-easy to write.
Pft, you can separate content from presentation with XHTML and CSS.
I will be getting a G5 for the sole purpose of running Logic6.
My Dell may be faster than a g5, but...damn, Logic 6! Logic Freaking 6!
Just wanna second the recommendation for the Kolb book (or any of his books. "Blind Watchers of the Sky" is good too). Rocky Kolb has a great way of explaining things so that it's interesting for everyone.
"And Canada does have the best health care system in the world!"
"Yes! Canada DOES have the best health care system in the world!"
(Kids in the Hall fulfilling their Cancon requirement)
It's tradition. Remember 1984's "Dune: STARRING STING!"
Starring Sting's pelvis, mostly.
Or SciFi's "Frank Herbert's Dune: Starring William Hurt!"
You've got to have a famous actor in a supporting role get top billing.
Well, this is entirely dependent on the quality of the ADCs in the guitar. Yeah, analog gear is limited by the CD format, but if you've got the right gear for doing the analog-to-digital conversion, you lose a lot less. This is why a lot of pro systems are sampling at 96-bits and 192khz - it's absurdly high resolution, far beyond the ear, but it's much nicer if you're going to be doing any processing on the signal. Your fidelity loss is minimized.
If you're working an analog-to-digital converter into a guitar that runs off a 9-volt, chances are it's going to be pretty craptacular. They say MaGIC is capable of 32-bit/192khz audio but they don't say that that's what the guitar is using. What you're more than likely to get out the back end is a thin and very digital sound. And if it's only CD quality, then what's the point? You're much better off getting a good mic'ed amp, getting some decent character into the sound (I don't care what anybody says about analog hardware - it's not the "warmth" of the sound that's the payoff, it's the odd little extra overtones, detunings etc that give you a good sound) and then run that into a really good ADC. Your end product will have much more going for it.
There's also questions about the internal signal path of the guitar - how hard is it going to be to wire in a good set of pickups? Say you want to swap in a set of EMG's or Seymour Duncans for a different tonal characteristic - can you do it with a soldering iron and some tape like you can now, or will you need a degree in electronics and a good logic probe?
The Hex Pickup is nothing new. You can get 'em for bass now, you can get 'em for guitar, and I've even seen comparable systems on violin. Sending on separate channels isn't a big deal. You can do cool stuff with it right now in terms of transposition, etc. The ARP Avatar guitar synth (the beast that killed ARP corporation) could do that back in 1978. That was synthesis, but even with the more recent hex-pickuped modelling effects units (Roland COSM for example) there's still some latency. It's not bad if you're just effecting a signal. It's if you want to manipulate the pitch, timing, attack or whatnot that the trouble occurs. The problem has always been one of tracking; pitch isolation is pretty slow no matter what signal format you use - there's elements of crosstalk from other strings, there's overtones to worry about, pitch "deformaties" from picking, issues with bending and portamento etc etc.
And the final problem is this - how well is Gibson going to provide this format to other vendors? Will you be able to get a MaGIC Fender? Or buy a synthesizer that speaks MaGIC? Will this have significant advantages over existing digital audio and sync formats? Will you be locked into Gibson gear? Gibson's track record for technology has been awful - they pretty much killed the ever-promising OMS MIDI-routing system when they bought Opcode (right when the PC version had started to mature) and refused to release the sourcecode to developers despite a large petition. Really, the last thing the music world needs is a closed format for recording, especially one limited to Gibson-and-affiliates.
Except - we can't know all the ramifications.
This is the fun of non-linear dynamics, commonly called "chaos theory."
Weather is the classic case of sensitive dependence on initial conditions. Butterflies in China and all that.
As nice an idea as it would be to just say "no bad weather" we could really, really screw things up. "No bad weather now! Yay! Whoops, we just flooded Oregon!"
Part of the problem with this is designer's environment - they've all got excellent monitors and great eyesight. Arial 8pt looks fine and is all hip when you're used to that sort of thing.
Stick 'em on a crappy laptop and give them the slight nearsightedness the rest of us have, suddenly I think everything would be at least 12-point again.
Or, they're disabled and have to use a text-to-speech browser. Which functions kinda like lynx.
If they're using lynx, they could be web developers who are tsting their site for 508 compliance.
This is one of the theological pitfalls of monotheism. If you have an omnipotent god, you get all sorts of fun little paradoxes.
i.e. can God make a pie so big that even He couldn't eat it?
Reagrdless of the answer, you're left with an non-omnipotent god, which goes against the omnipotent monotheistic ideal.
Many philosophers have spent a lot of tiem rationalizing this out. Otehres have spent a lot of time using this to prove that God doesn't exist.
Polytheisms don't fall victim to this, since rarely do they ever have or need an all-powerful god-figure. Gods/goddesses with specific domains don't need to be all-powerful to get their jobs done. Of course, polytheism has other theological problems.
Theological philsophy is interesting to study. Brain-hurting sometimes, but fun.
I wouldn't really want to be either gaming or running 3d apps on a laptop anyway. To do anything really serious you need non-battery-powerable hardware anyway - good monitor for graphics, external audio interface for studio sound (not counting PCMCIA interfaces, but the latency of those bugs me), satellite dish for remote-controlling Mars probes...
I've got a SmartStep 250 myself, and I knew about speedstepping, and I really didn't care. I've owned 4 laptops now and I think I've had them all on battery for a total of 10 hours. If it's running at 1.1gHz and all I'm doing is email, it's plenty fast enough. If VS.NET takes an extra minute to compile (hey, stop laughing, it pays the bills) that's just that much more time to drink coffee and read Slashdot.
I've seen a lot of peole complaining about the guv'ment legislating their freedom of website-expression with section 508.
.gov or a .state.us then it's likely you need to comply to section508.
Well, there seems to be a bit of misunderstanding, and it would've been better had the reviewer mentioned this.
Section508 applies primarily to governmental websites. So if you're a
If you're a federal or state contractor you may have to comply.
If you're not one of those things, do whatever you want.
However, it may still be in your best interests to at least consider accessibility. You may not necessarily comply with all the W3C priority 1,2, and 3 standards but a few of them isn't going to hurt, and are generally common sense. There's a huge market out there for the disabled - if you ran a brick-n-mortar shop you wouldn't turn away $175billion worth of your customers, so why do it on the web?
It's not like *all* of them are blind, deaf quadraplegics. I know people who use expanded fonts just because their eyesight isn't *great* - they're still legal to drive with glasses, but reading fine print on a screen necessitates assistance. Variable font-sizing and alt tags would suddenly open your website up to a lot of people just like that.
Basically, to help make a site more accessible it doesn't require much - start with your alt tags, maybe longdesc if you're feeling generous, try not to deisgn with 7 layers of nested tables, and use relative font sizes. Most sites won't even need to be fully overhauled to accomplish this, just tweaked, and it can open up the availability to hundreds of thousands more people.
It's not about being politically correct, it's not about avoiding lawsuits, it's about doing what's best for your website and delivering your content to the widest audience.
Well, it's not so much the problem with screen readers - that's just it. How do you screen-read something that's blinking? Or screen-read a picture without any information about what it is? Or screen-read a lovely layout that is position-sensitive?
:)
That's the issue - there are things that rely on visual cues, which just *can't* make the leap to screen-reading.
There are other problems too - screen-readers aren't the only devices used for accessibility, as the visually-handicapped aren't the only disabled people using computers.
There's a large number of issues to take into account, but frnakly none of them are too daunting to plan for. One can make a lovely and useful website that's fully s508 compliant as long as you're thinking about it in the deisgn phase.
And the DIV tag is your friend.
Ideally, yeah, they shouldn't.
But 45 gazillion web users, designers, and coders thing otherwise and thus, they do.
Slashdot readers/sysadmins/code jockeys are not the intended audience for the web anymore. Once, sure, now the web userbase is the masses. The users want what they want, and it's arrogant to the extreme to have a few of us dictate what that is to be.
Conversely, some users take things to the extreme - 10 non-standard fonts on a page, multiple flash animations, overdesigned pixel-specific everything...but there is a line everyone has to walk.
Usable Web Pages Do Not Have To Be Dull. Aesthetically Pleasing (in other words, "fly") Web Pages Do Not Have to Be Unusable.
Geeks need to remember that this isn't 1993 anymore and Tim Berners-Lee is no longer the only driving force for web development. Artists need to remember this isn't 1997 when a hip design got your site noticed and brought in sales.