Let people decide this with their browsers, and never specify sizes in pixels. It looks awful on small monitors (say, PDAs, or Grandma's 640x480 monitor), and it's awful AND hard to read on a 1600x1200 display.
It's true, but every line of a text document shouldn't have more then 85-90 characters (including spaces) for readibility. The recommendation for technical documents is 65-70 chars.
Also, if you want people to read from the screen you should:
Use sans-serif fonts, for example Verdana or Tahoma. Arial isn't very good.
Paragraphs must be short, i.e. few lines.
If you you pretend your documents to be accessible from mobile devices, _don't_ use fixed width tables.
For the time being, avoid to define font sizes in CSS, it doesn't work in different browsers/platforms. If it's a must, define different CSSs for IE/Netscape and Windows/Linux/Mac. Fonts are smaller in Mac and Linux.
Don't use backgound images, it adds nothing, but annoyance, to the content.
Don't use PDF as your main text format, it's very disturbing for reading specific text in laws/regulations/technical specifications.
sorry... it's getting long, you also must avoid extra large pages as/. pages;-).
Yes, and I don't understand how can slashdot (timothy) can title AltaVista Gives Up On Email when the original article is entitled AltaVista pulls plug on free Net access.
Its subtitle is even more clarifier: "AltaVista is terminating its free Internet access service, making it the latest company to exit the market".
Obviously the poster (krow) and timothy didn't read the article before broadcasting this mis-information. I think slashdot editors must take its job/hobby more seriuosly.
The problem with those packaging formats is when you install a new package, for example webalizer, that requires newer version of libraries, for example libpng and zlib, and you cannot found the RPM files for your distribution (for example Redhat 5.2, Suse 5.1, etc.etc), so you install the new packages from a tar file of converting the RPM to a CPIO file.
The result... after a couple of months installing softare or hacking a little the machine, RPM databases become inconsistent and useless, and you must go back to the ancient but reliable tar.
It's really bad that after 1 year a packaging format (and/or local database) become useless due to inconsistencies or newer packaging versions*. It deter expert users from using those formats and my mother from updating her system.
* And better not to talk about dependency nightmares in old libc5 systems.
It seems you've forgotten Java, Javascript, VBScript, ActiveX, plug-ins, COM interface to other Win32 programs,...
I've seen/done very complex enterprise applications with Javascript/VBscript and ActiveX objects. Or "non-developed" applications with very complex string pattern matching for automatic text formatting using _only_ javascript regular expressions. And they only work with IE.
DISCLAIMER: I am a C++ developer, not a web developer but sometime I have fun with "web no-developing".
There is a misunderstanding. No Spanish spoken "intellectual" is asking US companies* to write sofwtare or web pages in Spanish, but asking to Latin american companies and individuals to create contents in Spanish and to use the spanish technical words instead of English ones.
I am against this politics, or better to say "efforts", but I am biased, because I like English and I can read, write and speak fluently in this language. The last in not true for the 500.000.000 people whose mother tongue is Spanish.
If you analise the web pages of Latin American companies, the majority of them are written in English or have a translation to English. But this is not true for French or German companies, for example, although I don't have the right figures.
* But not for huge companies such as Microsoft, they have the same monopoly in spanish spoken countries, however the translation to Spanish of MS software is normally of bad quality and the spanish versions and service packs are released much later that their English or German counterparts.
Yup,
but I don't see the increased Dell's challenge in selling desktops. What did they do? Did they develop additional drivers? Did they modify Xfree source code? Or just selected the proper graphic card?
Having a "server" version of RedHat 6.2 and installing Gnome is not such a _big_ challenge.
You are not only rude, but also you lack of a minimum sense of humor. I don't believe very much in rules of thumb, that was my intention when I tried to add a little of sarcasm by saying "we don't drink coffes at all".
And I mentioned this book because it was referenced in the survey. It also mentioned Brooks' (his surname is "Brooks", not Brook, read the cover page, not only page 19:-) was given the Touring award, so he _should_ be right.
So, take it easy guy, we all know youve read the book. Indeed, although I am not Williams Shakespeare (Cervantes neither), I can read (and write a little) of English.
This is not a new topic in already studied in the Brooks' books.
In page 20 it says:
1/3 planning
1/6 coding
1/4 component test and early system test
1/4 system test, all components in hands
That yields 1/2 for testing and only 1/6 for programming. If we assume that programmers in small companies and start-ups do at least the three first phases (I guess that the fourth one is for customers Alpha/Beta), that gives us:
Planning: 94 days
Programming: 47 days
Component Testing: 70.5 days
Total: 211.5 days/year
Given that a labourable year has about 45 weeks*5days= 225 days (11 man months), which means, that according to Brooks' distribution of software engineering work, those programmers only spend 0,66 man months a year for coffes, reading, research and so on.
One of the figures lies, or we work more than 11 man months a year or we don't drink coffes at all.
Compression and chromacity artifacts are _not_ a "pixelisation" problem and the lack of color space in 32 bits.
And the biggest problem to achieve an agreement for digital movies is: distribution (encription, licences, and so on) and projection equipment costs. Nothing more. No big technological challenges. HDTV has (had?) higher resolutions than 36 mm films, which has less about (I don't remember the exact number) 2000 columns. Digital effects are produced at higher resolutions.
And, more important, _nobody_ complaints about bad resolution or colours in movies and TV, but the lack of stories and stupid scripts.
The pixelisation effect (aliasing) does also appear in films. A films is not a continous, but is covered by fine grains that are sensible to the light. Exactly as a a standard CCD camera, but with a high resolution. Nevertheless, last CCD cameras can provide the same or _better_ resolution than standard films, mainly if you are using films for low light lavel, which uses coarser grains, and therefore they provide lower resolution.
Furthermore, human eyes aren't analogic at all, we can normally distinguish no more than 600.000 different colours, so 32 bits is more than enough for "normal" eyes (or complain in the same way as those vinil fans regarding digital audio...).
Most of the "analogic movies" are post-produced already in digital, so quality and resolution is not a problem. Perhaps the only one is how to achieve the same "chromacity", but defintely, aliasing and colour resolution is not a problem.
May be you are right, but for a spanish spoken person, it's a good book, it helped me a lot for writing my PhD in English.
Nevertheless, I wanted to mention "The Mythical Man Month", not the "Elements...". It was a lapsus, because I bought those two books at the same time from Amazon.
You are right, I can hardly bear those people that think that everyone at Redmond is a dumb idiot and open source programmers are the most clever around.
It's clear that Linus, Alan Cox, A. Arcangeli, Miguel de Icaza etc. are extremely good, but they are extremes, not the average.
Most of European companies and Universities get lots of funding from the european comission R&D projects.
Every project consortium (formed by companies from several countries) are managed by an officer designated by the EC. Most of these officers force those companies and universities to do "exploitation" and "dissemination" activities in order to continue the funding.
Of course, to them, a patent, even stupid ones, are excellent exploitation results. Most of the times, when commercialisation of the product becomes hard ro too expensive, a patent is a good way to justify the funding.
I am not sure which one is evil, EC officers or european companies/universities...
As mentioned in other articles, Emb Qt doesn't use X. The X is not only the server but also the communication protocol between the applications (clients) and the the server. It's not only the X server which imposes large overheads, but also the protocol management and delays.
OTH, I really believe that PDA will/need get closer to PCs, not only in the UI but also in the API and programming strategies. 30 years of evolution in UI programming, which was a big success in home computing, cannot be forgotten or changed so easily.
And the success of PDA is based on their similar look to standard PCs and the new applications that allow to do on a PDA similar tasks as those you can do in your PCs, speciallly Internet browsing, emails and personal information management.
The human brain hardly can process more than 25 to 30 frames images per second. Furthermore the images persist for about 0.05 to 0.1 seconds in our retinas. Cinema and TV are based on these samples values.
What it's important are image and colour resolutions. These discussion alreade took place when defining PAL standard. NTSC produces 30 fps, PAL only 25, but with better resolution.
And for graphic boards, it's more important the amount of polygons per seconds, which strongly depends on transfer ratio between RAM and VRAM (see PS2 threads....). I would say also that given that textures add a lot of realism with "little effort", it's more important to support lot of textures than more than 60-72 frames per seconds (yes, yes, its sounds as Murphy law, but it's serves aslo to avoid screen refresh artifacts).
Did you notice that MS stock prices have increased since the theft? This is the first case I know where a theft increases the value of the victim.
What if MS realises that opening the code would increse their values even more? Would we have another, but a real giant RedHat?
I am amazed, I cannot understand the investors, unless they are geeks. Just in case, if someone here is thinking to rob source code from Oracle, tell us, I will buy some shares;-)
It's in sourceforge.
--ricardo
Also, if you want people to read from the screen you should:
- Use sans-serif fonts, for example Verdana or Tahoma. Arial isn't very good.
- Paragraphs must be short, i.e. few lines.
- If you you pretend your documents to be accessible from mobile devices, _don't_ use fixed width tables.
- For the time being, avoid to define font sizes in CSS, it doesn't work in different browsers/platforms. If it's a must, define different CSSs for IE/Netscape and Windows/Linux/Mac. Fonts are smaller in Mac and Linux.
- Don't use backgound images, it adds nothing, but annoyance, to the content.
- Don't use PDF as your main text format, it's very disturbing for reading specific text in laws/regulations/technical specifications.
- sorry... it's getting long, you also must avoid extra large pages as
/. pages ;-).
--ricardoIts subtitle is even more clarifier: "AltaVista is terminating its free Internet access service, making it the latest company to exit the market".
Obviously the poster (krow) and timothy didn't read the article before broadcasting this mis-information. I think slashdot editors must take its job/hobby more seriuosly.
--ricardo
--ricardo
The result... after a couple of months installing softare or hacking a little the machine, RPM databases become inconsistent and useless, and you must go back to the ancient but reliable tar.
It's really bad that after 1 year a packaging format (and/or local database) become useless due to inconsistencies or newer packaging versions*. It deter expert users from using those formats and my mother from updating her system.
* And better not to talk about dependency nightmares in old libc5 systems.
--ricardo
But yes, you might be right, although I would say is european custom.
--ricardo
I've seen/done very complex enterprise applications with Javascript/VBscript and ActiveX objects. Or "non-developed" applications with very complex string pattern matching for automatic text formatting using _only_ javascript regular expressions. And they only work with IE.
DISCLAIMER: I am a C++ developer, not a web developer but sometime I have fun with "web no-developing".
--ricardo
I am against this politics, or better to say "efforts", but I am biased, because I like English and I can read, write and speak fluently in this language. The last in not true for the 500.000.000 people whose mother tongue is Spanish.
If you analise the web pages of Latin American companies, the majority of them are written in English or have a translation to English. But this is not true for French or German companies, for example, although I don't have the right figures.
* But not for huge companies such as Microsoft, they have the same monopoly in spanish spoken countries, however the translation to Spanish of MS software is normally of bad quality and the spanish versions and service packs are released much later that their English or German counterparts.
--ricardo
but I don't see the increased Dell's challenge in selling desktops. What did they do? Did they develop additional drivers? Did they modify Xfree source code? Or just selected the proper graphic card?
Having a "server" version of RedHat 6.2 and installing Gnome is not such a _big_ challenge.
--ricardo
And I mentioned this book because it was referenced in the survey. It also mentioned Brooks' (his surname is "Brooks", not Brook, read the cover page, not only page 19 :-) was given the Touring award, so he _should_ be right.
So, take it easy guy, we all know youve read the book. Indeed, although I am not Williams Shakespeare (Cervantes neither), I can read (and write a little) of English.
--ricardo
In page 20 it says:
- 1/3 planning
- 1/6 coding
- 1/4 component test and early system test
- 1/4 system test, all components in hands
That yields 1/2 for testing and only 1/6 for programming. If we assume that programmers in small companies and start-ups do at least the three first phases (I guess that the fourth one is for customers Alpha/Beta), that gives us:- Planning: 94 days
- Programming: 47 days
- Component Testing: 70.5 days
Total: 211.5 days/yearGiven that a labourable year has about 45 weeks*5days= 225 days (11 man months), which means, that according to Brooks' distribution of software engineering work, those programmers only spend 0,66 man months a year for coffes, reading, research and so on.
One of the figures lies, or we work more than 11 man months a year or we don't drink coffes at all.
--ricardo
And the biggest problem to achieve an agreement for digital movies is: distribution (encription, licences, and so on) and projection equipment costs. Nothing more. No big technological challenges. HDTV has (had?) higher resolutions than 36 mm films, which has less about (I don't remember the exact number) 2000 columns. Digital effects are produced at higher resolutions.
And, more important, _nobody_ complaints about bad resolution or colours in movies and TV, but the lack of stories and stupid scripts.
--ricardo
--ricardo
The pixelisation effect (aliasing) does also appear in films. A films is not a continous, but is covered by fine grains that are sensible to the light. Exactly as a a standard CCD camera, but with a high resolution. Nevertheless, last CCD cameras can provide the same or _better_ resolution than standard films, mainly if you are using films for low light lavel, which uses coarser grains, and therefore they provide lower resolution.
Furthermore, human eyes aren't analogic at all, we can normally distinguish no more than 600.000 different colours, so 32 bits is more than enough for "normal" eyes (or complain in the same way as those vinil fans regarding digital audio...).
Most of the "analogic movies" are post-produced already in digital, so quality and resolution is not a problem. Perhaps the only one is how to achieve the same "chromacity", but defintely, aliasing and colour resolution is not a problem.
May be you are right, but for a spanish spoken person, it's a good book, it helped me a lot for writing my PhD in English. Nevertheless, I wanted to mention "The Mythical Man Month", not the "Elements...". It was a lapsus, because I bought those two books at the same time from Amazon.
The book "The Elements of Style" answers your question better than I can.
It's clear that Linus, Alan Cox, A. Arcangeli, Miguel de Icaza etc. are extremely good, but they are extremes, not the average.
It's clear that the Linux^Hs bottom half still works properly, does it scale to menage-a-trois^H^H^H^H SMP?
Stupid comment, but I couldn't stop myself, moderate it down...
Of course, to them, a patent, even stupid ones, are excellent exploitation results. Most of the times, when commercialisation of the product becomes hard ro too expensive, a patent is a good way to justify the funding.
I am not sure which one is evil, EC officers or european companies/universities...
M$ should delay the release of .NET until P4 improves its speed a lot more, let me say, until it reaches 4.8 GHz.
OTH, I really believe that PDA will/need get closer to PCs, not only in the UI but also in the API and programming strategies. 30 years of evolution in UI programming, which was a big success in home computing, cannot be forgotten or changed so easily.
And the success of PDA is based on their similar look to standard PCs and the new applications that allow to do on a PDA similar tasks as those you can do in your PCs, speciallly Internet browsing, emails and personal information management.
--ricardo
I'm not sure about other countries, but in latinamerican and latin-european countries, fool's day is Dec. 28 (it's called "Innocents' day").
What it's important are image and colour resolutions. These discussion alreade took place when defining PAL standard. NTSC produces 30 fps, PAL only 25, but with better resolution.
And for graphic boards, it's more important the amount of polygons per seconds, which strongly depends on transfer ratio between RAM and VRAM (see PS2 threads....). I would say also that given that textures add a lot of realism with "little effort", it's more important to support lot of textures than more than 60-72 frames per seconds (yes, yes, its sounds as Murphy law, but it's serves aslo to avoid screen refresh artifacts).
--ricardo
MS stock rose 5% _after_ the theft was known.
What if MS realises that opening the code would increse their values even more? Would we have another, but a real giant RedHat?
I am amazed, I cannot understand the investors, unless they are geeks. Just in case, if someone here is thinking to rob source code from Oracle, tell us, I will buy some shares ;-)