Forum Moderators: open
Well, we can all laugh at Frontpage....yeah it is funny the things it does- and I would not recommend anyone to buy it to be honest, but that is my opinion :)
I wanted to make a head-up thread about some of FP's pitfalls...since we can all sometimes be pretty keen to put it down. If you think FP is bad for web design - please do not hesitate to give it full frontal.
Some things that I change that FP can give you no choice over.....and some things you wouldn't expect in any other situation.
1)
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
This is trash. It is the default for making a new page (quickest way to do this in Frontpage is CTRL+N) I notice that even when you make a saved template of a page, it will insist on inserting them when you open the page again.
2) Broken T ag<a/s
I don't know exactly when FP does this, but at times, it does a great job of it. (Especially) Broken P tags = no validation and who knows what the result looks like in certain non-MS browsers. All of the problems with broken tags is by using the WYSIWYG view, which is what FP is meant to be all about. To fix this, you need to know how to hand code yeah? Since this is the case, FP is nice for a "slap up" design, but not for writing the sort of code that would give your site the sort of direction it needs.
3) Handling of PHP
No doubt a factor in other scripting languages, but when I was dawdling along in learning PHP, when saving a page, all the escaped characters that are in character strings are replaced with something....else.
4) Nodoctype for your pages
Why should I have to bother....it seems to do everything else that I otherwise wouldn't consider as an "enterprise" web designer.
5) CSS Creation
Frontpage can make CSS quickly, but it doesn't add values like px or %'s to some CSS attributes that require it. Again, why should I have to know any better...what exactly do you pay for. It also won't check over itself for non-validating CSS that it implements by using the >>Format > Style option on your .css page. IMO if the option intends to make CSS for you, it should make CSS that will actually work.
6) Webbots and Extensions
Are going to add to the cost of your webhosting, and if your host doesn't take that into account, the non-FP extension users will have something to say about that and their hosts business model ;) I have also seen a thread here in WebmasterWorld that references a program that looks for the Frontpage extensions on a windows server and simply wants to mess the extensions up...meaning every Frontpage you rely on (including Frontpage forms for feedback or anything you consider important) - useless. I don't know how much of a problem that is.
7) Handling of Temporary Files
Under the >>Tools > Options menu, you have the choice of configuring different editors for each file extension. You might say (after finding out some of the above) that's a plus. Maybe not. Click on a database in your FP web and do your stuff. Find out hours later that it wasn't the db you clicked on to edit, but an obscure temporary file that sits in a temporary folder with many other copies of your same database....every time you have done the same thing in the past. (Before I knew this I had about 10 copies of the same DB in a temp folder!) If you ever need a backup of a database, FP is doing it, just it never mentioned it nor would you expect it. So make sure you don't click on a DB file when inside FP.
If you click on any other file inside Frontpage that opens in another prog (usually notepad) and want to see updates and actually make-your-work-happen - you have to click on the FP program again so that FP can do whatever-it-must to update the file you intended to edit. (IMO - just edit the **... file you click on FP thank you).
Basically, FP imports any edits you've made outside the program once you click on it again. If it asks "a more recent file has been saved- would you like to overwrite it - click NO...this is FP wanting to revert to what it assumes was the last edits you made to the file (which, as far as it is concerned- is the edits you do in FP). The same goes for if you close the program and it asks to import newer files...tell the program where to go by clicking no...
8) Shared Borders
Shared Borders are the best worst invention in ages. They are splayed a bit like frames but can get all screwed up in light of all the mess that is involved in editing pages. Basically, FP controls shared borders....and their is nothing else like them on the web as far as I know. Basically they are like an awkward "include" that you would otherwise use to include content of your choice. The advantage of shared borders is if you don't have knowledge of CSS to position things, HTML to
9) Edit / Replace
Although any edit replace tool is nice...especially if you want to place bad code (who/what writes bad code) .... then FP will help you clean up the mess that whatever or whoever made. The only problem is that it scripts all those things that FP will automatically include for you, such as a line like this
<!--webbot bot="Include" U-Include="hastobe.htmbtw" TAG="BODY" -->
Now, the idea of this FP "component" is to save you time editing and replacing any old code that you want to supercede.....but in the case of this "comment code"...it skips it. Great...maybe I wanted to change the includes I use - nevermind, best stick to -normal- includes....either that or spend a couple of hours on a few hundred pages that would take 2 minutes editing/replacing using another program.
10) The Frontpage Includes
The FP include function is under >>Insert > Webcomponent > Included Content. It is like any other type of include i.e. usually the code <!--#include file="whateryou.like"-->. If you use the FP include...make sure to delete everything you didn't make "on-the-page" apart from the <html> and <body> opening tags...or the include won't be included. Otherwise the FP junk mentioned in (1) will be there. It doesn't get displayed on the page...but its something that adds to fat code and increasing disk usage. Also, when a FP include is displayed...you get checksum lines like this.
<!--webbot bot="Include" U-Include="hastobe.htmbtw" TAG="BODY" startspan -->The stuff you really wanted and not everything else <!--webbot bot="Include" i-checksum="35763" endspan -->
That's an extra 120 odd characters weight on your page courtesy of FP code. See here [webmasterworld.com] as to why Frontpage should not have this 'facility' as it stands in future :). Even if file sizes don't matter in Google, the lines of code are not needed- and are wasted bandwidth. Most of my pages are about 6/8k in source code using 3 includes - so using FP includes would increase my file sizes by 10% with no benefit to nothing.
That is 10 things that annoy me most about Frontpage that come to mind. I make this thread thinking that some experienced FP users may have ways round the above, while those who use FP because of its WYSIWYG capabilities and assume that it does everything correctly- be aware!
I guess some people almost hate the prog with a vengeance. I would assume some people do so because of the way it stifles something that you want to do...build a web page! :)
Regardless of expertise, knowledge external to FP, or anything- the program has faults that can make a site substandard. I don't claim to be an expert designer, and I still use FP for many things (like link validation amongst others).....but try to place lesser reliance on the prog
I've used it for over a year and a half, same time I have been making websites. I know some of you designers have stuck with FP over the years and may have something to add. Non-FP users...why not get a spade and help dig the grave here?? :) At one point in time, you said "I will not design sites with FP because...." - so what were the reasons?
Otherwise I don't think there is a place on the web that rants FP in detail. Perhaps we could start it here (and for the sake of equality-have another thread about its plusses).
After all it is one of the most commonly used programs to make a website today. Perhaps not the mainstream choice of an expert..nonetheless...still a player.
dynamic
When I mention "static" I meant that there really is 3,000+ physical files individually named for the purpose of having the search engines indexing these "real" and not cgi/perl generated pages with the darn question mark (?) in the url that some engines won't index at all.
link verification
Does your text editor give you Normal, HTML View, Preview Mode?
I'm not saying people should not buy MS products or stop using FP -- XP is a definite buy (I have the incredible distinction of holding an expired MCP, MCP+I and MCSE id card -- but not employed in that field). Just that you really don't need FP to be productive as a one person web builder. However, creating graphics is another story...
It's not a "battle of the editors" or "who would ever use such a program" for me - but how to use the prog in the best way.
Evidently, pageone has corrected me on a few sortable things-otherwise I have "no comment" on FP :) Usability to produce end results...in double quick time..I think that's about the length of it.
The biggest "no-no" I've found with the program is that
1) Yeah, the WYS is not the same as WYG (quoted from above
2) Some of the "universal" code it implements is not necessarilly good code.
I've always felt that someone should have a webpage "timing" the processes that can be done in FP and DW (or any other editor) and see what WYSIWYG produces the code (if perfect) in the fastest time.
Alias, the ideal editor...I want to just press a key and it makes the page for me! ;)
I've always felt that someone should have a webpage "timing" the processes that can be done in FP and DW (or any other editor) and see what WYSIWYG produces the code (if perfect) in the fastest time.
Don't forget "look and feel" and personal preference, both of which can affect speed. Years ago, when I was writing on typewriters, I could write faster with an Olivetti electric than with a Smith-Corona. And when I worked in a newsroom (this was in the early 1970s) that still used manual typewriters, I could write faster on a 1941 Royal than on an Underwood of the same era. Why? Beats me. I guess I just felt more comfortable with the Olivetti and the Royal; other people swore by Smith-Coronas and Underwoods. Similarly, I feel a lot more comfortble with FrontPage than with Dreamweaver, probably because it has more of an editorial/word-processing "look and feel" and started out as a Windows program instead of inheriting some of its characteristics from the Macintosh.
For that matter, I found the GEM version of Ventura Publisher easy to use back in the early days of desktop publishing, while other people (art directors, mostly) thought Pagemaker was much more intuitive. And in the early days of PC word processing, I found WordStar and XyWrite more conducive to productivity than WordPerfect was. Different people prefer different tools, and the end product (or, in the case of publishing, the revenue generated by the end product) is what counts.
Tough question lioness. Its all relative to that persons learning capabilities. Both programs have a steep learning curve to venture into the advanced areas. As far as the WYSIWYG environment, I of course will tell you FP has an easier learning curve because the interface looks very similar to MS Word and other MS applications.
I used DW for about a year and never really got motivated to dig deep into the program. My initial reaction was that there would be a steep learning curve because of the unfamiliarity of the interface.
If you are an avid user of MS applications, FP will have the easier learning curve. If you are an avid user of Macromedia applications, DW will have the easier learning curve.
Lets not forget that neither of the programs teach you about basic html. That is the first step in understanding what the program is doing when you click on a WYSIWYG function or feature.
Those of you who have used both FP and DW, what is the learning curve to learn DW?
Why doesn't your question include the learning curve of learning raw HTML? Since pageoneresults says:
Lets not forget that neither of the programs teach you about basic html. That is the first step in understanding what the program is doing when you click on a WYSIWYG function or feature.
After all, isn't HTML the basis of these programs? Anyone learned all three?
Anyone learned all three?
Not learned them as such, but I'm using dreamweaver more...much more 'dynamically friendly'. As already mentioned, its more a matter of comfort, but in some cases (as mentioned on my first post) frontpage will not make the code you want it to - even when you explicitly hand code it.
IMHO, the learning curve of DW will be roughly the same, hopefully with the person in question knowing a bit of background HTML knowledge and syntax. Otherwise I'd say its just-another-program.....a program where you need to know where everything is and what everything does :)
That's what I'm trying to get used to. I think it will take a week or two ;)
I started with text based editors and developed a process for site design that works for me over the course of several years...the learning curve isn't all that steep...it's a matter of having confidence that you can do something presentationally AFTER setting up the structure...learning to structure a document with html is fairly easy
I used Dreamweaver in a job for a few weeks to stay consistent with other on the same project...it didn't seem tremendously difficult to learn to do the basics and all in all it seemed moderately good software for tinkering with an existing site if you are uncomfortable with dealing directly with the document source...it has some useful site management tools which are fairly easy to learn to use...I just find it quicker to use a good text based editor and a quality FTP programme
I used FP for 9 months on a project and felt like I was fighting it every step of the way...if it can be configured to operate more efficiently than a text based editor then it requires techniques that don't appear anywhere in the documentation...it's very easy for a beginner to use FP 2000 to make a vaguely adequate site...if it is possible to use it to work effectively on a professional basis then it requires more learning time than I was prepared to put in
so
text based...initial learning curve is fairly steep...but gets easier
Dreamweaver...moderate learning curve all the way
FP 2000...easy to learn at first...very difficult to learn to use well
my own view is that neither Dreamweaver nor FP are tremendously good at css based sites...I wouldn't recommend learning either at present until they produce a genuinely css based WYSIWYG editor...since it will just be spending time learning something that is close to obsolescence
a better idea IMO is to use a well featured text based editor and Top Style...a combination that rates up with DW and FP in terms of saving time...and which will be usable for some years to come
I have that plugged into note tab pro....just learning how to flick around with the libraries.
Hopefully want to use this and Dreamweaver instead of FP.
I agree with your approach to FP. It has been more or less the same way with me.
Remind us why you didn't use it, or workarounds for its pitfalls
Thank you Eric for your input! I agree with your comments 100% especially this:
a better idea IMO is to use a well featured text based editor and Top Style...a combination that rates up with DW and FP in terms of saving time...and which will be usable for some years to come
I can honestly say that if I couldn't use DW, I wouldn't go back to FP, though. I'd use Mozilla composer for tables and HTML-Kit or something similar for coding.
Hopefully, this isn't too off-topic, but we have a Red Hat Linux based server, Apache 1.3.26, and everything seems to be working OK, except that the webbot tags in the text aren't always parsed. Some are working (such as the hit counter) and others (EG: Navigation) aren't. When you look at the published page, the <!-- webbot [yatta yatta] --> remains in the HTML and isn't being processed.
Any idea why this is, and how I can fix it?
Any ideas?
