Facebook Browser History Management Bug In Firefox

I had mentioned this issue in a previous blog post, and I think I have identified the root cause. If you use Firefox to browse Facebook, at some point, content will begin to fail to load. This is because of malformed URL often generated by AJAX history management libraries when they do URL replacement or add tags to the URL to help them keep track of history (essentially manage what happens when you click the Back, Forward, or Refresh buttons on the browser). You can do two things about it - either reopen the link in a new tab (so there's no history), or edit the URL as I'll show you.

To reproduce:
(1) Fire up the fox and log into Facebook. Your URL should look something like this:

(2) Click on the "Messages" link. It should open your messaging area, defaulting into your inbox. The URL should look like this:

(3) Click on the "Home" link. It should bring you to your Facebook home page. The URL should look as in the image below. Notice how the URL looks a bit weird - and that's the beginning of the problem. The more you browse around, the more URL chunks are appended at the end of the current URL.
(4) Click on the "Profile" link. The URL looks like that in the image below. This will fail to load content most times, as I described in that blog post.

If you want that URL to work, remove the part between the domain and usually before the last #. So, http://www.new.facebook.com/home.php#/profile.php?id=73002299 becomes http://www.new.facebook.com/#/profile.php?id=73002299, for example, and it will work.

This is only one of many ways Firefox users will run into this issue. Any combination of browsing history will most likely come to the same conclusion, and it's not pretty. Facebook totally needs to fix this bug, or they risk frustration from Firefox users that with think their site sucks when their favorite browser is used.

Trends In Web Development

Any interactive website you visit on the Internet these days has web applications running behind it. The applications do all the work and most content is generated on the fly - as opposed to the old model where static pages were served from a web server somewhere. Gone are the days when plain HTML was sufficient to give you a web presence - users demand (and deserve) a highly dynamic web experience now, complete with multimedia and personalized browsing.

How you make this happen is beyond basic HTML skills; it calls for pooling graphic design, database, object-oriented programming, and scripting skills in the mix to get even the simplest web applications up and running. I just finished a small AJAX webapp at work, but it used a variety skills including HTML, Javascript, XML, DWR (or JSON oriented client/server transport mechanisms), Java (with servlets, JSPs, and JavaBeans), SQL (database) and data access methodologies (DAOs, connection pooling, keep-alive), Perl (for the user scripting aspect), C/C++ (for access to OS and native libraries using JNI), and security (session and identity management). For such a small project, it sounds like a lot of skills to pour in - but this is the trend in the web development world. No longer can you survive on one particular skill; your technical worth is directly tied into how diverse and related your skill set is.

There's also an increased shift to developing web applications using regular software development cycles and models. Websites are now versioned in content management and versioning systems just like your typical enterprise product. Build cycles exist and well as integration cycles and such.

Web development tools also continue to take prominence. No one writes code from scratch these days - that's under-productive, like reinventing the wheel. Instead, serious developers maintain templates or use rules-based code generation engines. I particularly like tools that can take all my UML junk and produce code from it - all the classes and stubs I will need. So much time savings there.

In mentioning tools, you've got to consider IDEs and plugins. It is no longer sufficient to know how to use only one IDE because projects come in all shapes and sizes. I routinely use NetBeans and Eclipse on the same project, for example, because of the various benefits each offers (especially in the area of add-ons). Mind you, each skill you will need to use may have its own IDE, so you've got to stay on top of it all.

Building the application itself isn't sufficient - it has to be tested: performance, usability, security, and stress. I don't care how good a developer you are, but there will always be bugs in written code. I've stuck with Java for a long time because of JUnit and other testing fameworks. NetBeans has a profiler, and Eclipse has code optimization for various platforms. I often write a test suite that leverages Javascript's power for each web application I develop. Suites such as this are good for regression testing whenever changes are made to the site.

Here's where experience does some good: on a few projects, we've been able to write large chunks of webapps as Java code only and have CSS, HTML, and Javascript generated on the fly - using rules. This is becoming a huge hit because it eliminates having huge code bases: essentially the application server "knows" how to produce content at the point of request. It also reduces coding errors greatly and aides maintenance. Such systems are highly scalable because you can retask them, for example, by simply changing the rules. They are harder to design though.

Something to always remember is that web code is no longer proprietary. It is easily reverse-engineered (look, functionality, etc without legal consequences) that there's no point in trying to protect Javascript and other client-oriented features. I laugh at people that try to prevent downloading images, for example, by disabling browser menus. Do they forget that if you can see it on your computer, it IS on your computer? Waste of time. If you have to protect something, leave it at the server.

Finally, it's a can of worms when you consider personalized browsing. Everything from targeted ads, to personalized look & feel, to presentation of related content and session management fall under this umbrella. It's a sort of social engineering done in software, once again eased by rules-based computing. Beyond that, reporting strategies, tracking, data warehousing, and all that crap I don't do well - the web application isn't complete until most of this stuff is in place. Web development is no longer a piece of cake.

So those are just a few observations from my latest project. I'm actually relieved it's over - it was beginning to drain the life out of me.

Basic UI Design With JavaServer Faces (Pt. I)

In May, I wrote a post about getting JSP-based webapps to use JSF. Based on that post, we will convert our existing timecard utility to a JSF-based web application. The steps in the JSF post are largely good enough, with exceptions that I mention in here.

Be prepared to write a whole lot more code. The coding isn't hard - it's the repetitiveness and time you spend doing it that takes the steam out of it.
Beyond changes required by JSF (config files), we only change the JSP (add JSF markup) and bean (make it managed). In the end, we still get the same look and the application accomplishes the same things as before.
This implementation has 60+ components (areas, fields) on the page that need to be updated dynamically. The bulk of them are in the display table itself, and the rest are the various total and summary fields. We keep it simple in this example and use only <h:view>, <h:form>, <h:inputText>, <h:outputText>, and <h:commandButton> for JSF markup, although we could have just as easily implemented a <h:panelGrid> for the table.
You have to start worrying about session management. Case in point, if the view expires (either because the application was restarted or the session expired), you start getting exceptions like "javax.servlet.ServletException: viewId:/index.faces - View /index.faces could not be restored" caused by javax.faces.application.ViewExpiredException. That means you have to start over, as JSF emphasizes navigation/page flow (you need to start at the beginning).
JSF does not cure issues you already had in the JSP solution - all the bottlenecks and inefficiencies in algorithms will still be there. In fact, you might end up tossing lots of code, such as those that depend on parameters and field names passed from the client. It's true that pure HTML is generated by the JSF framework, but fields never have consistent names, especially when the view is regenerated.
I might add that JSF introduces its own issues - hints that designing a JSP app can be quite different from JSF - the need to plan everything and stick to the plan. They just behave differently.

Source code:
# The JSF-aware JSP file (index.jsp).
# The overhauled bean to support JSF (TimecardBean2.java).
# The other classes and pages remain the same.

After deploying the webapp, it's now available at <domain>:<port>/<webapp>/index.faces (as opposed to the usual <domain>:<port>/<webapp>/, which would have called index.jsp). Even with the <welcome-file> element set in the deployment descriptor to open the *.faces page, SJSAS web server does not get it right. Though, you can set NetBeans to open the page specifically (debug/run).

Some NetBeans 6.0 (M9) quirks:
(1) You don't get the option to reset encapsulated attributes' access levels when generating setters/getters, so remember to precede them with 'private' during declaration.
(2) The IDE no longer has a means to select all variables [Select All button] for which you are generating setters/getters. In fact, it also no longer allows you to select which getters or setters you want on one screen - how it was done in version 5.5].
(3) Whenever you add breakpoints in debug mode, you have to "debug project" again = compiling and deploying to a debug-mode server. Quite inconvenient, as some may wonder why breakpoints are not working.
(4) Code completion is case sensitive. The whole idea of this feature should be to reduce having to remember variables in your classes/pages. Now I have to remember whether I capitalized something or not?

Dynamic Web Content With JavaServer Pages (JSP)

Anytime you go to a website and it knows who you are, or asks you to log in, or you can do tasks on it, etc., that site is no longer static. Such dynamic websites run at least one web application to accomplish all those tasks. It doesn't have to be complicated really - a simple mechanism that responds autonomously to user requests can be considered a "web application". The previous timecard utility application was not dynamic. If you hit [Update], nothing happens. In this post, I describe a strategy to give that button some life. The result is shown above.

There're several ways to create dynamic web applications, including ASP and PHP, but I chose to use JavaServer Pages (JSP) to implement this functionality. The idea is simple: when a user clicks the update button, send all the data entered into the page to the server and update totals (lunch/work hours and week summary on the right).
This arena takes a basic web designer into the world of programming. Several tutorials exist on the web, including Sun's JSP Tutorial and the Java Tutorial. With these two resources, I've never really needed to buy reference books.

My implementation here simply uses JSP in its most popular form - mixing scriptlets and HTML code. When the page is called, it checks for a required session object and if none exists, creates one. That session object holds the dynamic data we need in parts of the page.
The session object is written along JavaBean conventions, but since we do not use it as such in this example, it can be any POJO. That class does the actual calculation of the times. The strategy is to use the principles of OOP for most server-side programming. Here, the timecard object depends on a Day object (which represents a typical day's hours - a column in our table), and a Week object (which represents all the Days of a week - the whole table). Each Day knows how to add up its own hours, and the week knows how to add up the computed hours from its Days to create a summary.

In NetBeans:
(1) Update the JSP code.
(2) Add new Java classes: TimecardBean.java, Day.java, Week.java, and a utility/helper class for formatting and parsing times and dates - DateTime.java.
(3) Deploy to the web server.

# As the code show, we are now naming fields of the form dynamically so that we'll be able to read them back easily. Also, business rules are implemented concerning the accumulation of work hours. For example, all day hours are rounded to the nearest quarter hour, and a mandatory lunch period is deducted if someone works more than 4 hours (and doesn't take lunch).

It's as simple as that - and you have a dynamic web application. Our code now also reports any errors it encounters and catches a few exceptions.
Possible problems so far with this kind of solution include a slow user experience because whenever the update button is clicked, the web server clears the timecard object and repopulates it with data sent from the client, recalculates all values, and regenerates the HTML to send to your browser.

Skills Needed: Basic Java and JSP programming.
Technologies So Far: HTML, CSS, Java.
IDE: NetBeans 6.0 (M9)
Web/App Server: Sun Java System Application Server 9.
JDK: 1.6+

Dress Up HTML With CSS

So far, our basic web designer knows how to write HTML and can run web applications on a web server. He has designed a mockup UI for the timecard utility, and although it doesn't do anything yet, it can be used to polish requirements. This is a followup to Simple Applications On Basic Web Servers. The prototype so far doesn't offer much visually and does not look that professional, so our goal here is to make it somewhat visually appealing. You do this with CSS.

You'll be surprised how many web designers and programmers out there have no idea or do not know how to use Cascading Style Sheets (CSS). I was one of them - I was comfortable doing database and business logic programming that I did not care much for how content was presented - that was another team's responsibility. However, as I began owning whole projects, I found it necessary to understand the presentation of content. It not only makes me a more well-rounded developer, but has affected how I do development. Thanks to my friend Ben who helped me get started. [By the way, Ben runs the BenTedder.com web design business].

Basically, CSS defines how HTML elements are displayed. All major web browsers support rendering web pages with style using CSS. There's several tutorials and books on CSS - it might be advisable to invest in a current desk reference, although you can find pretty much everything you want by simply searching the web. Theres even websites that have complete templates and programs you can use to generate CSS code for you. Although they make work easy, sometimes it's better to know how things work under the hood - whole reason to read up on CSS and learn to manually write code. The W3C CSS Tutorial is a good place to start; reference books you buy should be advanced beyond the basics on that site.

Here are some advantages of using CSS, including ability to make layout and visual changes for multiple pages from a single point, reduction of HTML code base, separation of style from content, and ease on search engines (find content rather than style). You should always know though that different browsers behave a little differently to CSS. Your best bet is Firefox to do better, as it is more compliant to standards than Internet Explorer is.

There are several CSS Editors on the Internet, most of them free or open-source. There are applications too that can generate both HTML and CSS through a visual design process (Adobe Dreamweaver MX??). The NetBeans 6.0 (M10) IDE also includes a CSS editor, which we will use to dress up our timecard application.

1. Add a CSS file: File | New File. Web -> Cascading Style Sheet [Next]. Name the file (maintimecard), and specify a folder (style) [Finish]. Will be accessible as style/maintimecard.css.
   
2. Edit the CSS: NetBeans' editor has quite a lot of features including code highlighting, code completion, macro recording, style builder, and preview. At this stage, we don't need to be looking for another editor.
3. Link the CSS to the HTML file and update the HTML: you'll have to manually edit index.jsp to link to the CSS file and the HTML to use CSS styles specified. Here is the CSS and HTML code.
4. Deploy the application.

When you display the application now in a browser, it looks like this. (IE shows a slightly different look, especially that it misses showing the dotted line right below "work hours" line).


How about that? We even add the idea of displaying messages to the user right in the form. Visually, this is a far cry from the basic HTML look we did before.
When I do development though, visual appeal is the last thing I worry about. Usually, you design your business logic first, then the database, and finally the presentation (HTML and such) when you know everything else works. In some projects, visual components are not polished until a later version of the software.

Simple Applications On Basic Web Servers

Perharps the single most important implementation decision a web programmer must deal with is their choice of platform. When you start coding, the server-side components are usually specific to a language or platform. As an example, if you choose IIS, you'll initially be stuck with Microsoft technologies; if you choose Apache Tomcat, you are choosing the Java path. Of course plugins abound that enable additional features, such as Tomcat behaving like an IIS server, or to run PHP scripts, etc. But this decision usually determines what "camp" you belong to.

A basic web server simply responds to HTTP requests and socket connections. Since we are leaning towards implementing our solution in Java, there are plenty of servers - as listed here on Java-Source - that are free/open-source. Apache Tomcat is perhaps the most popular web server on the Internet today. Though in this exercise, we'll be using the Sun Java System Application Server, which comes bundled with the NetBeans IDE. As usual, I choose web servers based on how easy they are to configure, if my favorite IDEs support them, if they can be debugged on, level of complexity to extend, ease of deployment, and industry reviews that may suggest their performance is production grade. Later as your application grows, you start worrying about clustering and load balancing, response times under pressure, security, etc.

A scenario was presented in a previous post: the need to implement a simple timecard utility. To be able to do "live mockups", you need to have a real web server to which is deployed a foundational prototype. To start with, we'll create a simple application that dishes out HTML representing a basic UI. Instead of using plain HTML files, we'll take advantage of JavaServer Pages to generate the HTML. It also sets us up to use servlet technologies to respond to HTTP requests and ability to dynamically generate content. Many other server-side technologies do the same thing, including ASP, PHP, and ColdFusion, for example.

Often when you do web design, you start with mockups of how the final product might look like. Along with requirements from your client, you might then come up with use cases and such. We'll use NetBeans 6.0 (M10) to create a simple HTML based mockup:

1. Create a new web project: File | New Project. Choose Project = Web -> Web Application. Project name and location = TimecardWebApp; context path /Timecard. [Finish].
2. Design your page: index.jsp should be open in the IDE. Just code HTML into this page. Here's HTML code of what's needed to produce a mockup. NetBeans includes a palette that allows you to generate code for basic components using simple drag-and-drop onto the page.
3. Run the application: right-click the web application -> Run Project. This will start up SJSAS, which is our web server in this context, deploy the web application to it, and open up the page in your default web browser. It should open at http://localhost:8080/Timecard/.

That's all for this step, and you should have something that looks like this:

Of course this page does not do anything yet. We are only interested in the look of the application in order to visually show the client what we will be able to do. The idea is that a user will enter the hours they came to work, took their lunch, left for the day, and any holiday or sick hours awarded. When they hit [Update], it should update the totals. That's all for now - additional features will be added later as the client specifies them (in future posts).

As you can see, IDEs such as NetBeans make web development a snap. Beware with v6.0 M10 though: the full package install take upwards of a minute to get started, and code completion/JIT is still painfully slow. But the advantage with using this IDE is its simplicity of use, available features, and how quickly you can get applications done. Of course whenever we need to implement something, we'll try it first in NetBeans; if it's not possible or there's a better way, we don't want to feel stuck in this IDE.

From Simple HTML To Advanced Web Technologies

In these days when even grandma can design and maintain a website - sometimes for free, what value can a web designer or programmer add to justify paid work and interest in their product? I get pretty irked by designers that crank out solutions in pure HTML, and fail to take advantage of web technologies and standards that'd enhance the user experience, make design/programming a breeze, and take advantage of the latest technologies. Most of these things are available for free on the web.

So after chatting with a few developers that are stuck in HTML-only web design, I decided to start this series to demonstrate how you can take a simple HTML application and use all kinds of standards and technologies on it. I'm talking Javascript, CSS, Flash, AJAX, Direct Web Remoting (DWR), JSF, and a myriad other web tooling and presentation APIs, such as Yahoo!'s, Facebook's, or and Google's. I'll approach this series from a Java perspective, exploring everything from using EJB 3.0 for your data layer, various design models and patterns that may apply, and considerations for developing your own components for improved efficiency. We might also touch on issues with various containers and application servers, load-balancing (in code?) and taking advantage of modern IDE features that take the headache out of programming and design. What about designing for mobile devices? We'll see how that can be done.
Another idea is to find a good application or website and reverse engineer it - that's the ultimate learning curve. Since this is essentially "educational" and "research", you are not bound by copyright and other legal issues - as long as you don't steal their code.
Finally, integration with .Net and other technologies is a possibility. What would it take to port application to various environments, or at least have them play together? Of special interest will also be finding out which is the easiest and least expensive way to implement such a solution.

The application I'm choosing for this exercise is a simple timecard utility that can be extended to include features related to time management. This doesn't sound hard, does it? I mean, you can have a prototype literally overnight. All it does is present an interface where users can punch in the hours they worked, and it calculates the usual paycheck. The basic prototype is manual and simple, but it enables us to have something simply functional and see how the various technologies can be used to enhance it. Simple goal.

That said, I'll do Java development in the NetBeans 6.0 (M9) IDE. It comes with the Sun Java System Application Server 9, and that's pretty much all that's needed at this point. Of course you should already have a Java EE 5-aware JDK (1.5 or later). Eventually, we'll need a database to store our information.

Freedom of Fonts in Web Browsers

I really do not think it should be up to web page designers to dictate what font you view a web page with. There are websites you visit and you can hardly read content because someone specified some insane font style and size for the page, which works well if the viewer's web browser is left in defaults. If you in fact have the fonts and can do the sizes specified, trouble happens. I wish I could just avail a few fonts to a browser and force every website I visit to be displayed in just those few fonts as desired.
Also, don't developers ever test their sites across browsers any more? I've come across a few websites that work well only in IE or Firefox and suck in other browsers. Even if you develop for IIS only, it's imperative you test on other browsers ... unless you don't care about visitors that exercise freedom of browsers. At least have a disclaimer if you have to go that way.

For the rest of us that customize our browsers to the tee, including specifying a font and style, it becomes an annoyance. Preferences change often, but I like "Californian" and "Courier New" at 10pt for my pages - small font. If I were to visit a site that attempts to reduce the font size by 3 points (relative), for example, the text would be unreadable. This is where Firefox excels at giving control to the user - you can specify a minimum font and the browser ensures that all font sizes are always above that size. I don't know anywhere in IE where this can be done. In Firefox, you also have to unselect the option that allows pages to choose their own fonts.

I always recommend that when you design web pages, the bulk of your content shouldn't have restrictions on what font styles and sizes users should use. Most users customize these two things, and you'd be abusing your authority as an author to restrict that freedom. It's understandable for fonts that must fit on images or certain fixed spaces such as menus and ads. Developers that use templates that calculate font sizes based on available space, etc, are prone to this problem. I discourage using relative font sizing (e.g. <font size="-3">) for text that can be manipulated by browsers. User preferences with fonts and styles can also mess up your menus and such that depend on fixed spaces. For such, images are the way to go - to promote consistency.