Firefox 1.5
Well, the browser space just got a little more complicated. Mozilla Foundation today released Firefox
1.5, the follow up to their next generation browser.
Right now I'm working on upgrading the product I work on for Firefox compatibility… yes I know, if it was designed using web standards I wouldn't be having this problem, but as I mentioned in a previous
post, this particular app wasn't designed by me AND was build using Visual Studio (2003)… which SUX. Due to the timeframes involved and the workload associated, I'm in the unpleasant position of having to retro-fit the existing application to MAKE IT work in Firefox (and as such, Safari and the rest of the compliant crowd… except Opera… two words "Modal Windows").
To be honest, I am fast coming to the conclustion that now would be a very good time to re-write the UI from scatch. With IE 7 due to hit the ground in the first half of 2006 and nothing even closely resembling a feature complete beta in sight I am getting very nervous about the amount of work we are creating for ourselves in our current venture. Only time will tell…
On another note, the Jury is still out on Visual Studio 2005, I have heard varying stories from the good to the bad and have yet to find the time to actually explore for myself. One thing I will say is that upon initial inspection the HTML code editing does seem to be a significant improvement over VS2003, and although they still insist on calling it the "Design" view at least it doesn't appear to be re-writing (Read: f$#@ing up!) my code!
3 Comments so far
Leave a reply
Hi Simon. Nice to see you hammer your thoughts out with such force. What sort of issues are you seeing with FF incompatability? I trust you've got the browser caps update in your web.config or machine.config? Client side validation doesn't work with FF, so you always need to make sure you're using Page.Validate and Page.IsValid server side too.
Re the VS2005 designer – there is one place where it will actually change your code – but as I recall, it only removes whitespace. If you have an unordered list (ul) nicely formatted in html view, then switch to design view and update one of the list items (li) then the designer will remove all of the whitespace between each (/li) and the next (li). Something trivial like that anyway. That's the only report I've seen of it modding HTML so far. Much much better than 2003.
Nice to know somebody is reading my ramblings
I will of course now have the rename the blog however! 
Yes, we have set the browscap in the config files so that FF isn’t treated as a down level browser (how arrogant is that term???? Deep breaths… don’t get me started
. Re the un-ordered list re-writing… Visual Studio 2003 has done much the same as you mention but will on occasion remove all but the last /li closing elements as well. I use unordered lists along with a splash of CSS (sliding doors) and a sprinkling of JavaScript in place of the tab and multi-page controls as it is a far cleaner leaner solution (not to mention, in the right circumstances, lending itself to semantic markup… not SO important in this instance) and while it doesn’t actually break in either IE or FF it just bugs the hell out of me when one of our developers (who has the IDE set to open files in design view by default) needs to tinker with things.
I think my biggest gripe right now has been the apparent complexity involved in designing… or rather working with a web UI for an ASP.net application, and to a certain degree I guess some of the blame falls, not at the doors of MS… well not directly anyway, but with the way in which original solution has been developed… by software developers, not web Designers. In some places there are controls nested three and four levels deep all rendering various parts of the whole (with god only knows how many tables!) and being called from numerous locations. Hence my statement to the effect that, rather than retrofitting to solve the application woes in FF it would most likely be a better use of resources to systematically re-write the UI from the ground up… something which I believe we will seriously have to consider.
I used to work with classic asp and php and while, with both those languages there was little in the way of code separation, it was far easier to work visually AROUND the developer’s code than it now seems to be with asp.net. I recall hearing, right back when MS were first touting the .net framework, how it was finally going to solve the problem of separation between code and presentation and while I truly want to believe that, in all my experiences thus far I just don’t see it being a reality.
In all fairness I am probably being overly harsh on asp.net. Given time I would like to get to know C# and ASP.net better and be able to interact more effectively on a design level with the code behind the application. But to be honest… with all the other presentation skills necessary, a lot of web designers are only ever going to have this basic “Understanding” of the business logic side of the web and there should be the degree of separation to which MS and many others have eluded.
I cop a lot of flack in a room full of developers as you can probably imagine
Hey Simon, Good to hear about these things from a designers perspective. I'd have to agree with most you've said. ASP.Net certainly usurps the power to design from the designer.
If a website is built well from a developers perspective, it probably will be broken down into controls that will be nested several levels deep. If the developers done a good job, most design elements will be seperated out into the css (and table use will be minimised).
However, this still doesn't make it easy for the designer. Sure, if you want to tweak some colours, fonts, paddings, background images or whatever, then edit the css. But if the designer wants to do something simple like add a new image, then it's likely the control responsible for rendering the surrounding html will need to be found and tweaked. Sometimes this can be tricky for a developer who understand the code, let alone a designer who shouldn't need to know about C#. In some ways Community Server is lauded for it's skinnability – but I've come to realise this is only by those with a penchant for pain. Ask Phil (a very capable designer and developer) what it's like to skin Community Server – a "well written" asp.net app.
So what can be done to make these web apps easier for a designer to modify?