The information gathered that makes up your browser fingerprint includes: browser type used, plug-ins installed, system fonts, and the configuration and version information from your operating system. The possible implications of this means it’s possible that cookies or an IP address would no longer be needed for identifying a unique individual or machine. The browser fingerprint could be a substitute for that as a means to identify.

I visited a research project of the Electronic Frontier Foundation called Panopticlick, which creates a fingerprint for your browser, then lets you know how unique your browser appears, and how much information is shared. I tested my own computer using two different browsers and both appear to have unique fingerprints among the 1,241, 361 other ones tested so far. This makes sense, that even on my own machine, the two fingerprints are different because I use those two browsers in different ways for assorted tasks, and don’t have the same plug-ins for both.

Some are concerned about their browser fingerprints being used in a harmful way to track people and their activity when they don’t want to be. But your browser fingerprint has already been used for years by site analytics software to accurately measure Web traffic, plus provide visitor platform and browser statistics.

There are other ways that sites can use your fingerprint in positive ways, like checking your plug-in list to warn you if you lack something necessary to view the site, or (as mentioned in previous Lunch Pail posts) to display an optimized page or experience for a particular browser version or mobile device. Fingerprints have even been proven useful in the detection and prevention of online identity theft and credit card fraud.

The use of fingerprinting by companies, in my opinion, is a good thing as long as it is for just and ethical reasons. If a company is going to identify me to personalize my online experience while making it optimized as well, then I’m ready to ride that train.

To maximize the efficiency of a mobile buyflow event, the software platform uses mobile-device detection, plus multiple page templates and style sheets to ensure the proper page is loaded for the device used. We also develop a lowest-common-denominator template for our mobile buyflow sites, so even if the URL is hit via a computer web browser, the user can still follow the steps and purchase a product.

So, if you were to visit one of our dynamic mobile landing pages and compared it side-by-side with an Apple device or Android OS device versus a BlackBerry device, you would see an entirely different look and feel. This is based upon the template used and the style sheet called for. When using mobile-device detection, we can also customize the experience per platform and device as well.

For example, BlackBerry has multiple devices and screen sizes, so the new BlackBerry Torch can utilize a style sheet designed for that device and OS, while a BlackBerry Tour would use another. Also, since Apple and Android OS devices let users rotate their devices, our device optimized templates and style sheets adjust for that as well.

Considering all of the above factors and technologies, the goal is to help a mobile-device user feel at ease, be able to smoothly follow the purchase sequence – from landing page, to product page, to product customization, and finally checkout – in a useful and functional way. All are important considerations when selecting your own mobile buyflow solution.

Follow-up to Monday’s post:
On Monday, Chris explained the geo-marketing trend in social media. Check out McDonald’s results with their FourSquare campaign.

Like most technology projects, it is difficult at times for certain project team members to imagine a finished product. That is why there are meetings, technical specifications, wireframes, mock-ups, development/testing environments and even ad-hoc releases before going live to the world. Creating something so technologically driven, and somewhat new for an organization, can be challenging. These types of projects are usually new to most of the people involved in a project. Plus, everyone wants their piece of the pie represented when possible, which creates multiplemajor stakeholders and requires different data points that must all be brought together and logically made into a single cohesive app with a stable backend.

As a technical project manager, the first thing my customer and I need to have is an agreement on what our project is going to produce. I can’t manage expectations effectively unless there is a common expectation from the start. It may seem obvious, but the first, and most important, step to managing expectations is to establish a common understanding of the solution that is to be delivered. Normally this is done with the customer’s approval of the project’s technical specifications. Having customer approval signifies that they understand and agree with what is to be delivered, how it will be delivered, and when major milestones and delivery will occur.

Once a common expectation is reached, you then need to communicate proactively regarding the status, issues, response times, and risks associated with the project. You have to stick to the timetable agreed upon and provide a resolution, or a progress report. Then get all of the work completed on time. If it is determined later on that the expectations cannot be met, the customer should already be aware of it through proactive communication, then gain a new common understanding of the project based on the updated circumstances.

I find that assuring customer expectations are managed properly from the start makes all the difference for any project. Think about how many of your frustrations are caused because you expected something to be different that it was. If you had known what to expect, you would not have been as upset during the normal twists and turns of bringing a mobile app project from concept to market.

Trying to compare the two device platforms on the basis of applications seems a little unbalanced. Apple’s apps, the tools available to develop them, and the platform they get to run on excel. Non-RIM programmed BlackBerry apps, the tools available for development, screen resolution, and screen size trail way behind.

I can honestly say that since Knotice just created a mobile application on behalf of a client for both Apple and BlackBerry, that the iPhone is the easiest device to develop an application on. The Apple platform gives an application that “WOW” factor. We were able to create a beautiful iPhone/iPod Touch application with great design and slick user interface… only to turn around and simplify the application so we could retrofit it to function on the BlackBerry device.

The difficulties with BlackBerry development is due to the smaller screen size and resolution, poor data capabilities (especially with video), and the general lack of proper tools made available from RIM to tap into the same resources that their core development team uses to make their nicest legacy applications.

Knowing we had to develop an application that would be somewhat consistent across both platforms was a challenge for the team on this project. Given the parameters of the project, we could not shoot for the moon on the iPhone app because we would definitely leave the BlackBerry app in the dust. Even with our cross platform thinking approach, the honest truth is that while trying to have a sense of application balance we still could not achieve it because the Apple platform empowers developers and users alike, and the BlackBerry devices seem to hold progress at bay, given the tools RIM makes available to third party developers.

Needless to say, I am looking forward to making upgrades to the iPhone application and continuing to monitor the app development market, especially Android and BlackBerry.

It is important to be aware of mobile device capabilities, and, if possible, to use them as an advantage. The more devices a site provides a pleasant user experience on, the better. Creating and serving the correct markup for a specific mobile device and browser is the best practice. However, sometimes a small budget and/or a short timeline raises the question of building the experience for the lowest common denominator. The lowest common denominator approach is definitely of interest when developing mobile friendly sites because it is what classifies the user base and device preference. The goal is always to maximize reach despite any time or budget constraints.

Programming with the newest phones, browsers, and technologies in mind allows progress sooner with “slick” results. But, that approach may alienate older phones and browsers – and in turn potential users and customers – creating a call for a sense of balance. For example, developing a site that is geared toward the iPhone or iTouch, because those are the cool toys on the market, is not satisfactory since most mobile Web browsing is not performed on Apple’s devices.

Consistency is best in the lowest common denominator approach. Thinking cross platform, considering factors like screen size, navigation, and more commonly available technology provides access to a larger user base.

Project managers always want to encourage open communication while avoiding misconceptions and misunderstandings. It is the project manager’s job to often facilitate this communication by listening to and meeting with the project drivers – and at times the end users – who are usually non-technical people. The conversations with non-technical team members are invaluable because simply listening or even being shown what users deal with on a daily basis, can lead to project improvements that no one originally thought about.

Once a project manager gathers the project information and examples from non-technical team members they need to process the data and translate it into technical speak containing the specificity required by the technical staff to develop solutions.

Staying agile during this process is also invaluable because as the project nears completion and team members start to see examples of what is being developed and begin testing, new ideas can be discovered. The project driver may want certain items or improvements added into the mix before the project is considered completed, and fast translation of any new information is essential to meeting deadlines.

No matter what, open and frequent communication during technical project management is a key component because it keeps team members connected. The relationship between all of the technical and non-technical staff is needed to achieve project success, and the project manager is at the center of the process to make sure everyone understands each other, shakes hands, and gets along.

When a technical project manager is dealing 1-on-1 with their client they already know the client’s line of business, the usual players involved, and any potential obstacles such as guidelines, time zone differences, and the status of other ongoing projects that must be balanced. When another party – or even multiple parties – is added to the project mix it increases the complexity and makes successful project delivery more challenging.

Acknowledging that each vendor invited to the table has something important to share and the skills to back their ideas is important from the start. Each vendor must have a good relationship with the project driver and share common goals to make both the client and project succeed. Extra effort is needed in multiple vendor environments. It is important to understand any new partner’s relationship with the client, how they usually work together, get to know the new staff involved, and then adjust for the possibility of added time zone differences or even a language barrier.

Success with a multiple vendor project is accomplished easily by providing technical specifications that the client project driver signs off on at the beginning. A project driver must clearly define vendor roles, responsibilities and deadlines. Then the project manager must manage expectations among the different teams, conduct regular meetings and provide communication strings, and build a positive working relationship.

The project manager must work hard on the stability of the project while maintaining the working relationships of all the parties involved. It’s important for the project manager to communicate often with the client, the other vendor(s), and the development teams as problems arise, objectives change, new information arrives, and/or when goals are met. Everyone needs to stay on the same page.

Communication, collaboration, and a shared goal of delivering a strong project on time should certainly outweigh the challenges, and can actually be a rewarding and exciting experience.

Many marketing-driven projects do not have a thorough, rigid project plan. As a result, incremental testing is necessary – a method that requires extreme attention to detail and an emphasis on delivering a quality user experience while ensuring the security of the backend code.

When testing on a project’s initial phase is complete, the project is ready for review by the customer marketing group. Because incremental testing has occurred throughout the entire process, errors are minimal and only a few small items require tweaking.

Here’s a good rule that is always helpful: Some of the people doing the final testing should not be familiar with the project, the code, and the user experience prior to pushing the project up to the production environment. Having fresh eyes available for testing gives the development team a new perspective and assists in finding potential mistakes that others, who are more deeply involved with the granular details of a project, may overlook.

Following these, and other guidelines too numerous to mention in this post, helps to deliver a quality product that contains stable, bug free code. While testing is important to ensure the stability of the code, it is also crucial for creating a positive user experience. An agile development process creates the right conditions for incremental testing, sound code, and ultimately a positive user experience after the project goes live.

Knotice’s Scrum method helps us recognize that potential problems cannot always be completely defined or even flushed out, initially. The goal is to maximize the project team’s ability to deliver projects quickly and respond to incoming requests or changes, no matter when they are made. That process and approach makes project teams more productive, reduces mistakes, decreases development time, and delivers a project on time.

Frequent communication helps team members know what’s already been done, what needs to be done, and what hurdles exist that may prevent a project goal from happening on time. Also, team members may be working on a variety of projects at the same time, so everyone needs to know what others are working on, who is responsible for what and when each piece of the project is due. Using this approach in marketing-driven technical projects allows for quick recognition of any potential troubles and also enables a rapid response and resolution from the development team.

Things can go wrong during the lifecycle of any project, so the best thing a project manager can do is plan for unanticipated issues, monitor the development process, and proactively keep the communication channels open to all team members. The agile management method Knotice employs makes our project plans flexible and helps us react more quickly to evolving needs while revealing possible mistakes well in advance.

Building an effective timeline for a marketing-driven technical project usually consists of working backwards from the launch or due date and pinpointing weeks ahead of launch each major component needed. The next step consists of building a sub-timeline for each milestone, then assigning the appropriate team members to help move the process forward and deliver their pieces on time.

Essentially, undertaking a marketing-requested technical project requires the following steps to define the timeline and deliver on it:

• Comprehend and pull together the individual project requirements
• Determine the timeline for the new project
• Provide a technical specification that fits the project requirements, timeline, and budget
• Determine the resources and team members needed to deliver results based upon the requirements
• Build a sub-timeline for each project milestone
• Implement the solution, work the timeline(s), manage scope, and deliver the desired result(s)

While marketing technical projects can seem difficult, fitting them into this process makes them manageable while providing enough flexibility to make adjustments as needed.