Don't use Word for editing Webpages!
 

I always save DOC files as HTM before I post them on our Intranet Home Page at work. It's just too easy with Word 2003. I used to print them to PDF, but Adobe reader takes forever to load on some of our slower machines. I know zilch about web design though. The new site looks great!

Jesus, the season is fast approaching! I need to get on the ball if I want to do my 60K maintainance before it starts!

Here's regular html:
Here's the same page generated by Word:
DON'T USE WORD TO EDIT WEBPAGES! :roll:

:lol: It works though. You're a victom of your own OCD. :P

No, he's like any programmer and hates badly generated code.

It doesn't "work". Take that Word output, now imagine there's some real content in there, bloated all to hell, and edit it with VIM in a linux shell. Chances are, it can't be done... at least not in any sort of timely manner. IMO, that's broken. Just because you live in a windows world, and can get by w/ half-ass broken documents doesn't mean the rest of us have OCD.

Plus, when it comes to bandwidth, your word document formatting could actually cost me money. The Word document is 30 times larger than the hand-edited one... if we were using 30 times more bandwidth around here for the same content, it would noticeably effect the quality of service, not to mention the cost of hosting.

And you write all your code in assembly language???

Human friendly "development" tools will always make bigger, uglier "code" that will often be significantly less intelligible when viewed at the lowest level.

But that is the price for improved "time to market" and other buzz word marketing terms.

Get over it. "save as web page" works even if you don't care for the underlying code.

Word is *not* a "human friendly development tool". Get Dreamweaver or something if you want an editor for html. Word is a huge PITA for editing with, and generated terrible code that doesn't look anything like it's supposed to!

If I "save as web page" and it doesn't look the way the editor previewed it, then it doesn't work.

As far as real RAD and code generation tools... you obviously haven't coded anything in the last 10 years... Good tools generated good code, that at the lowest level is extremely clear and matches best practices for software coding. Bloat is there in the code because it makes it easier to maintain the code, but code is *compiled into machine language*, which removes the bloat. A good compiler will turn long-winded code into the same machine language as if I had written it in assembly language.

HTML IS NOT CODE... it's not compiled, you have to transfer *all* the data to the client, so the browser can interpret it. There's a reason your old Reno SCCA site took forever to download (aside from the lack of hardware it's running on)... your index file was *massive*, 50% of which was unnecessary CRLFs, because you kept editing it in friggen Word. :roll:

If your STi was running on 3 cylinders, it's still running, but it's not working as it was intended. As an IT administrator, shame on you for not knowing the difference between beneficial high-level tools and bloated crappy code. Just because something comes up in a browser doesn't mean it's working right.

If you honestly believe compilers create code as good hand coded assembly, you are fooling yourself. And don't even start me on what happens when you use the word "Include".

And if the results of a "Save to web page" meets the needs of the person choosing to use it, it does work, car analogies aside.

HTML is code in this analogy, and word is the compiler from a higher level "language" no matter how good or bad it is.

Again, you may not like the old site, but it worked. and the old index.html file was 755 bytes. And the total page including graphics was under 60K

Many thousands of web pages are developed and maintained in Word, FrontPage, Nvu, Excel, etc... whether you like the results or not, they work. You can choose not to use GUI editors, that is your prerogative, but those tools work for many, just as your C# or other compiler works for you.

Talk about getting off topic.:rolleyes:

DON'T USE WORD TO EDIT WEBPAGES!

Actually, a lot of my professors used to argue that compilers could create on par with or even better machine code (e.g. faster and smaller) than coding assembly "by hand". Hand coding assembly is prone to human error and personal coding preference and style. Over the past 50 years of coding the best practices have been worked out for the simple and complex instructions and sequences. We can't guarantee that every assembly programmer can know all of these best practices, but with a good compiler and a decent higher level language, they don't need to.

Dean, I will guarantee you, if you were to develop something in ASM, you would get your ass handed to you by a compiler in terms of performance. Modern processors are so complicated these days, and incorporate so many pipelining tricks, caching algorithms, etc, that unless you knew every last register like the back of your hand (like the guy that wrote the compiler ;)) you can't approach the efficiency of the compiled code, especially if the person running the compiler knows what they're doing. No one uses ASM anymore, except for simple critical code that runs on an old processor. Hell, event the guys doing in-card 3D graphics have high level languages these days.

Also, I haven't typed "include" in like 5 years... what happened in a 1990's C complier is totally irrelevant with today's development suites, high-level languages, virtualized machines, multi-core processors, distributed architectures, etc. Programming these days is about leveraging existing libraries, not about fitting the executable on a single HD floppy.

Like I said, if I write a web page in Word, in the browser it better look exactly as I designed it in Word, or Word has failed as a WYSIWYG editor. Just because people are satisfied with broken software doesn't mean the software isn't broken.

Nope. In that analogy Word is the development tool, HTML is the output binary. The "higher level language" is Word's internal XML format, and the compiler is the "save as" function that converts the XML to HTML. That conversion in Word is less than piss-poor.

Sure, writing a web page in Notepad (or any raw text editor) is akin to coding in assembly, and I know it's not for everyone. But a decent html editor uses a browser for previewing (so you know it's accurate) and generates pretty, hand-maintainable, HTML. Word is the absolute *worst* choice for HTML generation. The whole point of HTML (and *any* markup language) is that it's human readable. Word completely defeats the purpose of the standard.

The old RenoSCCA site was slow and unmaintainable. Perhaps you don't remember the life cycle of system development, but it ends with "maintain". If you can't maintain the site, it doesn't "work". Remember, that site isn't your personal webpage, it has a very well defined goal of acting as a line of communication between the board of directors and the general membership. If the board is unable to change the information on the site at will, then the site has failed its purpose. Because it takes so much work to maintain, and because it can only be maintained by individuals with significant technical skill, the BoD cannot use the site as they require. I would say that makes the site a failure.

Edit: I just noticed the numbers in that quote... :lol: Your index file was a frames container... it could have been 100 bytes instead of 700+. Plus, you had to download all of the framed pages to get the content, which was almost 30k just for the top, navigation and main pages (and that's *after* I stripped and pruned main.htm down from over 45k itself!) and doesn't include the size of the link images.

Your site required the transfer of at least 250k (again, not counting images) to get the same pertinent data that I've got in under 18k of text in one index.html. Including my 7k in images images, I'm still 10 times more efficient.

Like I said, I'm not suggesting that hand editing HTML is the "best" way. If I were a professional web developer I certainly wouldn't hand edit, I'd use decent tools (like I did when I was a professional web developer). But Word is the worst... absolute worst... way to maintain a website, followed closely by FrontPage. And what the hell is Excel doing in that list? To bring back the car analogy, using Excel for web authoring is like entering a golf cart in the Indy 500... sure it's got a motor and four wheels, but it's the wrong tool to race 500 miles. Just because something saves to HTML doesn't make it a useful tool for editing HTML.

Markup language bloat is a real-deal issue. I see it everyday with the piss-poor XML based protocols we have to code to. We're going to see real-world bandwidth issues in the field because people in decision making positions have decided on tools and methodology without understanding the underlying technology. I bet those people use Word to edit their homepages too.

The schedule is there, it's just in a word .DOC (which is what started this whole tangent..)

Because I can't get to the server from my work PC, I can't edit the schedule and repost it in a more friendly format. I can try to get to it the next time I'm online from home.

Edit: please move this to the other thread. It got moved while I was typing.
______________________

You might consider splitting this discussion into another thread if you choose to continue it.

This is not about what you or I could do...

Compilers like GUI editing tools are just that, tools to increase productivity and permit more timely and practical creation of the end product without the requirement to understand all the underlying details.

While it might require significantly more time, a significantly different set of knowledge, and other resources, I believe significantly faster and smaller binaries to accomplish a given task can be done in assembly, period. It may well require many orders of magnitude in terms of that effort to accomplish those savings, but they are attainable.

Don't get me wrong, compilers are great, but a given compiler cannot produce "optimal" "machine" code for every given application no matter how many passes they make, or flags the developer sets. Abstraction is abstraction, and that is what compilers and GUI editors do, abstract the actual work from the human making the request whatever it is. Without detailed knowledge of the entire system, any results will be suboptimal to some extent no matter how small that may be.

Yes, HTML is the binary in my analogy, but you got my point.

Include was in quotes. Are you saying all your programs are entirely your own and don't rely on any external libraries, procedures, APIs, DLLs, etc. or whatever you want to call them? HA! All of those include yet another layer of abstraction was my point.

I get into these types of arguments all the time with developers and management types when they want a more reliable or fault tolerant end to end solution and believe throwing more hardware will magically provide the solution.

No amount of hardware will replace transactional awareness at the application layer. I can provide an infrastructure that runs at 6 9s, but that won't instantly make an entire end to end application 6 9s. The infrastructure is 3-6 layers abstracted from the application, it can't possibly have awareness of the application requirements.

Compilers make great code, but as they do not have complete visibility to the requirements, they will always create suboptimal code. This is why some portions of drivers and such for things such as video cards and network switches/routers that are absolutely time critical are still written in assembly even today.

Back on the web site. The old web site was maintainable at exactly the level relative to the investment of resources in it combined with the ability of the developer and the system on which it was run. :p

I wish you the best on improving it going forward. :)

Dean, the discussion was split off like 2 hours ago.

Here, let me help you out...

EDIT: Ah, all better.

I got distracted while typing. :P

Dean, all that talk about compilers, and yet no relevance to the problem with Word's awful conversion to HTML?

You might convince me that given enough development time, pure assembly development will out perform high-level language. But ASM is in itself a language... it still needs to be compiled into machine code. So, you might as well just develop in ones and zeros! Compilers are leaps and bounds better than I think you realize... but yes, it is a layer of abstraction. Your general point is taken: higher level languages reduce development effort and/or development time at the cost of code space/efficiency.

But that argument does not correlate to Word. Sure, you're reducing development time by editing in Word, but you're also getting orders of magnitude worse HTML. By using .NET I can program a system in a month that would take 40 years in ASM, and my resulting code would be maybe 1% bloated. By using Word you save maybe 10 minutes on a 60 minute project, get results that don't match your design, don't conform to the standard, and bloat the HTML by 10 times.

You can try to justify it with "but I'm knowingly trading bloat for development efficiency", but the results speak for themselves: Word is a terrible tool for HTML. Something like Dreamweaver (or whatever the pros use these days) would turn a 60 minute job into a 10 minute job and generate HTML that's 99% as good as hand-coded (if not better since it would most likely be more efficient with style-sheets and the like). I'm not arguing that hi-level development tools are bad; I'm arguing that for HTML, Word is not a high-level development tool.

My point with the "include" was to illustrate how outdated you are in terms of the current state of software development. People don't use C/C++, at least not for enterprise level development... it's too low level. I haven't used a makefile since 1998, and I haven't explicitly run a compiler since I started getting paid to program. Tools these days handle the includes out of sight of the developer. External code use is bigger than ever, hell .NET itself is a library that uses other libraries. The shear mass of code needed to do things like a SOAP based service oriented architecture would turn a simple distributed "Hello World" application into a 5 year 20 person development project if you were to do it in C with no external resources. But using these libraries now days is trivial, it's all built into the development tools.

This discussion started because you couldn't be bothered to put the schedule in a web friendly format that would have taken 8 seconds. Would it have been perfect, probably not, but that is what translators, exporters, compilers, etc. do. That is my point.

What you put in one end may not match what comes out the other side and is bound to be less than optimal. Heck, since you can't control the "interpreter" or browser that "runs" the "binary" that is the HTML, you have no prayer of ensuring reliable output without quite a bit of testing. And by the way, I retract my earlier concession. HTML is still code, not a "binary". HTML is an interpreted language with browsers being the interpreter.

Bloat is bloat, whether it is created by you choosing to put remarks in your hand coded HTML or it is created by the word HTML export translator.

OMG. I deal with developers using modern tools every day. I am using generic terms. What would you prefer I call the tool that creates your binaries? A "Studio", "Project builder"? Whatever....

Oooh, you can use big acronyms like SOAP, and XML... I architect multi-platform, mutli-site, highly available, highly integrated systems using modern and legacy systems / protocols, N tier applications, middleware, etc... Don't even start throwing around acronyms with me.

I apologize for not placing a "Visual" in front of my C# reference. I don't write code for a living, but work with people who do every day and often have to explain how things really work. I have been moving bits since the 8080 processor and before, so please don't presume to tell me how computers work.

Also, if you don't have to tell your "Studio/Bulder" how to find 3rd party and external libraries, you are either writing very focused "native" applications, or having very little interaction with other diverse systems. But again, my point is made. You have absolutely no visibility to the code you are calling, and have no clue to what extent it is bloated relative to your actual application requirements. How much memory is used, or how many extra branches are taken in that external code in the final binary?

How is that different than the bloat that Word, Front page, etc. add to HTML?

I work with modern developers who have no clue how their application actually executes on a machine, or how jobs, threads, etc impact the system the code is executing on much less other dependent systems.

Windows is compiled, and so is LINUX, why is one faster for some applications vs. the other. Must be compiler optimization. :)

Word is a terrible tool to create HTML, but an average user like Dave Deborde can click save to web page, and get results they can live with, especially on MS browsers in seconds. Why should they learn DreamWeaver or even Front Page, etc. if they don't need to?

And last but not least, assembly code only needs to be assembled into machine code by an assembler. There is a 1 to 1 not open to interpretation mapping from assembly into machine code. It is not compiled.

Dean, I think we're arguing an order of magnitude. Word's "Save as HTML" bloat adds unneeded bloat. Its adds open and close tags right next to one another. It'll fill in a file with whitespace characters and whitespace escapes. And its a pain in the ass to maintain unless you keep the word docs around and do it all again. And this doesn't even scratch the surface of the unnecessary stuff Word does in its HTML generation.

Where as a high level language may include significantly more lines of compiled binary, more often those instructions are not entirely useless. They add some level of security, sanity checking, exception handling, abstraction, etc so that a simple instruction doesn't crash the whole system.

And for me, the tradeoff for coding in higher level languages is a completely acceptable solution compared to the unacceptable way Word makes webpages. They aren't analogous in my mind.

As long as we're complaining about documents and objects accessible on renoscca, I have a question - why is the Feb. newsletter cut off on the right margin on pages 15 and 16?
And it seems like it took forever to load.

Also, I'm reasonably savvy with looking for things like schedules on web pages, but I can't find where there is a link to a document showing a Solo schedule. All I see on the main page is a link to a document under the heading for Trials. Someone give me another clue?

But it would have worked and everyone would have been able to view it crummy and large as it might have been, and it is not like he needed to reclaim the space in use by the word doc on his PC.

What is unacceptable about them? They are viewable by the consumer. The consumer's requirement is to see the schedule in a reasonable period of time without requiring an external application. Word exports meet this requirement.

Scott may have other desired features and supportability issues he wants addressed, but consumers often care little for these. :)

The link says 2007 Event Schedule on the right side of the front page

Thanks Mike.
It seems like that link is under the heading for Trials, I was looking for something specific to Solo.

Updatability. If the page needed to be updated, its ugly, unless you re-use the Word document. Once the whole site becomes ugly to edit like that, then the maintainer will start to drag his/her feet (understandably).

But, in a way you're right, the website has one function. That is to get information from the Reno SCCA BoD to the members and potential members in a timely fashion. In my opinion a Word as HTML only satisfies the requirement for members (in a barely acceptable manner), but doesn't satisfy the needs of the BoD to be able to update pages in a timely manner if the HTML is so bad it makes the maintainer unable or unwilling to take the significantly extra time to update the site.

EDIT: And I'm also arguing outside the specific instance. One time as a temporary stopgap, sure, fine whatever. I arguing about building a whole site (even a vanity site) in nothing but Word.

Its actually above both the solo and the trials headings, as it encompasses both.

If Scott sets it up so the secretary can upload the minutes and the newsletter editor can upload those, then they can use any tool they wish to create that content.

There are great content management systems that do amazing stuff but those are not supportable at this scale for the opposite reasons. You would spend more time managing the management system than just managing the content manually.

It all goes back to using the right toll for the right reasons. This is true for web content as it is for application code.

I agree with you, and wouldn't use Word to manage a core framed page with embedded much of anything. But it works fine for creating end pages especially Quick and Dirty. So does Excel.

I can't imagine hand coding or even attempting to import some of our Excel sheets into an GUI HTML editor. No matter how bloated the Excel exported HTML code is, I'd live with it. :)

A schedule is an end document, and thus Word is an acceptable HTML creator IMHO. This is especially true because the creator is likely to maintain it in Word until he is given a better easier tool, and even then, they may not choose to use it. Heck, I never did get some of our past board to stop using spaces for formating and thus had to recreate much of the material they sent me to make it web friendly.

This is what my screen looks like. It shows the link under the heading "Trials".

:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:

Welcome to different interpreters (browsers) handling even hand coded HTML differently....

It is fine in Firefox, but Debbie's version is how it displays in IE...

Maybe he should have used Word and then it would be right in IE... :devil:

What? If a browser doesn't output what the html tells it too, it's a broken browser. And yes the HTML is a code that will be interpreted, but it needs to be efficient because it's transmitted over the line. Because the interpreting happens at the end user, as a developer one should strive to generate efficient HTML, just in the same way one should strive to generate efficient binaries.

Sure, I comment my HTML in order to make it easier for me to update later on... it's bloat. But I'd never embed the state of my spelling and grammar check engines in my output HTML. :roll: Take a look at that Word output I posted earlier. It's *ridiculous*.

If you can't tell the difference between a development tool and a compiler I fell sorry for the programmers that worked under you. I'm not dropping acronyms to impress you, I'm mentioning the technologies that are revolutionizing the way distributed systems are being developed. They're not programmed the way you seem to think they are (circa 1995), they're build out of tools and building blocks. It's the difference between building a house out of pre-fab modules, and grabbing an axe and heading into a forest for logs. You make know how a computer works, but you're astonishingly out of touch with what it takes to build large-scale software.

I don't have to tell the development environment how to use external libraries because they're all included in the environment, and when the compiler is run, I'm linked against only the ones that I used. Again, welcome to modern software tools. Other tools we use in this century include code profilers, optimizers, unit testers, etc. We know what's going on in the code, how much memory it's using, what we're calling, etc.

Aside from the fact that there's very little bloat (when compared to the massive gains in development efficiency), the difference is that we're not transmitting our binaries over the network. 10k of bloat in a binary that's loaded into RAM once during service startup is a hell of a lot different than 10k of bloat in a file that's downloaded 100,000 times a minute.

You work with crappy developers apparently.

What's your point?

Maybe they shouldn't... but their ignorance to technology and tools isn't an excuse for you developing and attempting to maintain a website with Word and Excel, and arguing that it's a good/acceptable idea in general. You're supposed to know better, you know with all that "multi-platform, mutli-site, highly available, highly integrated systems using modern and legacy systems / protocols, N tier applications, middleware, etc..." architecting you do.

I want to punch IE in the nuts, it almost drove me insane when I was working on scoring software.

This is what I see in firefox:

I missed a '>' on a <td> tag. IE decided in its infinite wisdom that meant that it should move text up in the document rather than simply display it as it was received.

Either way, the fix took a whopping 2 seconds, including the uploading of the fix.

PHB: But, since computers are so fast now, and storage so cheap, and everyone's on high-speed, more code is good. Besides, IE loves it, and we don't want to be left behind.

Scott, I do not claim to know what you do on a daily basis, but I work with developers on at least 5 different platforms probably using 10+ thing I generously call "languages", and god knows how many different development environments. Those environments run from good old text editor - compiler, to pure object oriented GUI with no access to the actual underlying code and everything in between including .net. So what exactly is your current experience with development outside of .net in the '00s?

Based on my experience in the gaming industry as well as working with major consulting groups and vendors of middleware, hardware, and applications on a daily basis, the .net environment continues to gain traction, but is not the dominant solution for enterprise applications. It is obviously the major player in the Wintel space, but despite Bill's wishes, the majority of enterprise applications do not run on his products.

I find it hard to believe that your "development tool" already has all the "libraries" you might need to build an application that uses for example, say... EMS or Rendezvous messaging? And how does it know if you need to use the PGSQL DAL? Clairvoyance?

The right tool for the right reasons... The SCCA web site does not need a $100,000 content management system, utilization analysis, or intrusion detection.

Front page and NVU which are what most of the old web site was created in are perfectly acceptable tools for developing and maintaining small web sites, and Word and Excel are perfectly acceptable tools for text and spreadsheet types of content. Just because you don't like those tools doesn't make them unsupportable. Attempting support them in a raw text editor may be near impossible, but so what?

You just can't admit that for the purpose of publishing the bloody schedule on the "temporary" web site, Word's HTML output would have been perfectly acceptable and taken you those same 2 seconds you took to make the fix in your hand coded HTML "index" page...

So be it.

I'm done with this topic.

Wow :lol:

Yeah, I figured something was up. I know you know your way around computers to not miss something that obvious. Well, another mystery solved.

I'm not going to bother to re-write my resume just so I can reply to this post, but I'll tell you this: the .NET 3.0 technologies like WF, WCF, WPF, Enterprise Library, etc, are going to *crush* Linux/Unix based systems in the next 5 years unless they get on the ball 2 years ago and come up with something better.

And it's true, if I need access to something like PGSQL (though it'd be a massive step backwards from the ORM tools we're using in conjunction with MSSQL) I'd just pick it off the list of supported DALs. And for something that's not supported, I just get the installer and add it to the environment because 9 out of 10, the tool supports Visual Studio 'cause if they don't, they'll be out of business in 5 years.

And you're right, the SCCA website doesn't need an expensive CMS, it needs one person with a text editor and knowledge of PHP/MySQL. Frontpage would be a minimally acceptable means for maintaining the site if FP extensions were installed on that server... but considering the number of documents that are carrying the MS Office icon headers in them, I'd say you weren't maintaining it w/ FP, you were using word and excel, and bloating the site as a result.

As far as publishing the schedule on the temporary site... you just nailed it... it's temporary. If I wasn't waiting around for the DNS change, this page wouldn't even have existed. Like I said, at 1am when I was finishing up, I didn't feel like doing *any* file conversions, I just uploaded everything I was given as is. I'd much rather be in bed w/ my GF than freezing my ass off in the kitchen opening up word to save off a bloated .html file. Plus if I'm going to spend time on it, I'm going to do it right, because I take a little pride in the work that I do and don't feel good about half-assing things if there's a better solution out there.

I was just kidding about the OCD thing. :lol:

The level of argumentation in this thread has moved the board up to an Orange Alert.

This discusion is similar to the ones I have with people who put images in their email signatures. They don't get why it makes me pull my hair out.


MS should add '...in case of emergency only' after the save as web page option. Multiple animated character popups confirming this and trying to steer you to better ways should be there too.