Tips to Provide the Best Website Experience

If you were a website developer yourself, you wouldn't need the services of one. You would craft your website to beautifully present your corporate face; to be your product’s best display case, and to showcase the telling of your grand corporate story. Unfortunately, to many website developers, your website is simply a project for them to complete.

Hiring a website design professional is imperative these days, because the available site options are limitless and constantly evolving, and because the competition in your industry is fierce and getting fiercer. Understanding that a good website design can boost your business to the next level, and all the levels beyond, also means accepting that you are not qualified to be your website design professional. However, the professionals you hire to create it must be as sensitive to the aspirations of your corporate personhood as you are.

Web Site Design Processes Can Create Their Own Challenges:

There are lots of reasons why websites fail to produce the metrics to justify their development expense, many of which are a combination of both client and developer confusions:

1. Clients are looking for a visual and interactive account of their idea. Developers must craft visuals and components based on (often) ethereal commentary. Communication well before the design process begins can ease the connection between idea and end result.

2. Clients may have preconceived notions about how the site can function, without actually understanding the programming of the systems. Again, communication from both sides – what the client wants to see and what the developer can produce in response – is integral to finally getting it right.

3. Clients may want to control all aspects of the process, without accepting any but the most menial of input from the developer. A website that satisfies the client AND accomplishes the goals it is designed to achieve should be a collaboration between client and developer.

Excellent Website Design Processes Respond to Corporate Challenges:

As you contemplate your site's design options, there are a few concrete steps you can take into the first conversation:

1. Establish your goals:

Your goals will depend on the nature of your enterprise and how you want it to connect with your target market. Do you want to convert more customers? Provide valuable information? Expand your product base? Your website should carry the message of your enterprise mission – why you got into the business in the first place. Your developer should first understand the corporate back story, to better understand and connect with your website goals.

2. Identify Your Limits:

Unless you are really clear about what you do want, it can be difficult for the designer to understand what you don’t want. So be prepared to discuss the “do not do” list, too. The conversation can be about site specifics – no pop-up ads or left-column videos, for example – or more general concerns, like third- versus first-person text, or the location of testimonial pages.

Being open to developer suggestion is also a strong indicator of a true collaboration. The designer may have a programming option that creates exactly what (s/he hears you saying) you want, but because you don’t know his/her full arsenal of tools, you can’t know how valuable her/his suggestions might be. In other words, don't put your limits on development assets you don't yet understand.

3. Set a Flexible Budget:

Website design has cost features associated with it, of course, but its value is so much bigger than the dollar/per/hour ratio. The end product should be a manifestation of your entire corporate self, which is priceless. The return on the development investment may pay that expense back several times over, much more quickly than you can anticipate. And considering that digital marketing comprised only 28% of all marketing spending in 2014, an energized website might reveal the obsolescence of your other, non-digital outreach efforts, cutting those costs and saving you money overall.

You run an excellent company and are master of your enterprise. Hire a professional to ensure its internet face is as polished and functional as you need it to be. To get started, contact us today.

"Many ideas grow better when transplanted into another mind than the one where they sprang up." -Oliver Wendell Holmes

Why

About a decade ago, a new method for developing software efficiently and speedily began to take over the developer world. This method, Agile development, relies on a close collaboration between all team members and stakeholders. The Agile development philosophy includes keeping requirements and documentation concerning the product lightweight. In addition, the method recognizes that change is a normal, and actually an ordinary occurrence in software development. This makes close teamwork particularly important to clarify requirements and to keep all team members (including the product owner) on the same page throughout the development, and that "same page" is the product backlog in agile development.

What

A product backlog in agile development is a prioritized features list containing short descriptions of all functionality desired in the completed project. The product backlog is the system of record or the reliable data source for what teams should be working on as they develop a product or software application. In agile terms, it is also called the "information radiator," or the one place the priorities of the product owner are made clear and transparent to the team and anyone else who might be interested.

A typical product backlog is comprised of 1) features, 2) bugs, 3) technical work, and 4) knowledge acquisition. While every item, called product backlog items or PBIs, is logged into the product backlog not everything will be a direct description of a feature or function. Some PBIs might include architectural work, prototyping, and research. However, do not worry, just because numerous PBIs are there in the beginning, making the product backlog look unwieldy and all over the place, it will be "groomed" during subsequent team meetings. Grooming removes those PBIs that no longer appear relevant or that need to be reprioritized in keeping with the current understanding of the project and its objectives.

Who

A product backlog is compiled by those with a vested interest in the product being developed. It requires the input of the stakeholder or product owner and the team that is tasked with the building of the product or software. The compilation or filling of the product backlog happens in meetings, sometimes called sprint meetings, with the participation of every team member.

Focusing and giving real attention to this process is fundamental for every team member as this is the primary tool for understanding what is required for the successful completion of each sprint and ultimately the shippable product. Involving every team member in the process of the product backlog is essential, everyone can and should contribute to the creating of tasks listed on the product backlog, enabling the team to draw on different perspectives and generating a much richer list of features, functions, and knowledge acquisitions.

How

A product backlog can be as simple as post-its on a board, a white-board with items listed, or a spreadsheet. Many times each PBI is listed in the form of "user stories" and from those stories will come the task list that expresses the necessary work to be done. The hardest part of a product backlog can be the requirements list and a user story, when expressed correctly and used as intended, can describe a requirement with a bit of context, thus making whatever problem the feature is trying to solve understood.

The product backlog for a sprint includes every kind of task involved, including object modeling, coding, learning new techniques, database activities, and tests. Ideally, the team starts at the top of a prioritized product backlog and draws a line under the lowest priority they feel that they can complete in the sprint that is just starting. They may select some lower priority items that are associated with the higher items on the list because it will make sense to complete those during the current sprint.

At Contensive we practice an Agile development process that allows for total transparency. If you have any questions please do not hesitate to contact us, we want to be your online partner going forward and are ready to consult with you on your next project.

Fully responsive web design is no longer a luxury for your website. Google announced recently that it will punish websites that are not fully responsive. Not only this, but mobile commerce continues to increase. 2015 may be the year that mobile commerce as a whole overtakes other forms of digital commerce. This has already been the case for many years for many younger demographics.

You must make the switch into fully responsive web design today in order to build a lasting brand online. Here are three top tips that will help you make the transition or improve your scalability and marketability if you have already implemented it to some degree.

Natural Asset Scalability

The only responsive website design themes or templates that you should seriously consider using will include natural asset scalability. An asset is anything that a customer views as a separate piece of information on the screen. Pictures, text, buttons - all of these are separate assets, and all of these assets have the ability to scale naturally with the size of the screen that the customer uses.

Each asset with additional features on mouse holdover should retain those features regardless of size. For instance, navigation bar items with drop down menus must retain their menus regardless of the size of the screen. However, your web designer must make the menu fonts scale at the same rate as the original navigation bar asset to keep the website cohesive.

Sophisticated CSS designers may allow your assets to reorganize themselves if the screen gets so small that text cannot be seen. In some cases, assets that are less important may drop off the screen entirely if the user decides to reduce the display past a certain percentage.

Vertically Elongated Menus

For the most part, horizontal scrolling is panned in the world of responsive web design. People simply prefer vertical scrolling, and this includes menu scrolling.

If your laptop website has any menus that elongate along a horizontal path, they must repurpose themselves as a vertical menu. Many smart phones and tablets do not even allow for vertical scrolling past a certain point, meaning that your website may completely lose a menu item in a worst case scenario. Because the last item is most menus and along navigation bars is usually the conversion action or the sale button, you might imagine how this might negatively affect your business.

Hidden Toggle Menus

Between the choices of hidden toggle menus and on-screen toggle menus, hidden toggle menus seem to have won out. Hidden toggle menus became a trend in the iOS circles, especially those that used native Cocoa libraries for some incredible animations. The idea spread as more web designers found uses for the hidden toggle, and it has become such a normal part of the mainstream web design circuit that it is now the preferred type of menu animation.

There is one weakness to the hidden toggle menu: It relies heavily on Javascript. This may affect your decisions in the short-term, but over the long-term, Javascript will become a more integrated part of mobile design. If you are looking to create a site that will stand, then do not move away from the hidden toggle menu just because the majority of your users have mobile devices that are not yet ready for Javascript. Your web designer can create a fork that directs your customers to a Javascript free mirror if the device does not support the technology.

Please feel free to contact us when you need an online partner focused on time and cost efficiency. Our proprietary development process is based in agile scrum, a process that minimizes all time spent in bulky applications while maximizing value for your web design money.

According to Former Blue Angels squadron leader, George Dom, "When it comes to time and managing it, he says we perform best when we sprint at high energy for an hour on a project and then relax so the batteries recharge and then sprint again. That pattern allows for recovery and then peak performance across the day." With Dom's analogy in mind, let us look at the question "what is a sprint in agile development?"

First, agile software development can be described or defined as iterative or incremental. In an agile environment, every aspect of the software under development, such as the design and all requirements, is continually revisited throughout the process. This "adapt and inspect" paradigm greatly reduces time and money as it allows frequent delivery of product to the marketplace. The ability to deliver functional bits of the application as soon as they are ready is achieved through regular progressions of work known as sprints.

A sprint in the software business is a short cycle of development, in which the working group focuses on and completes a defined section of the product. Sprints, sometimes called iterations, typically last between one and four weeks. However, sprints can be shorter, lasting as long as one day, but they should not be longer than four weeks. A series of sprints will run, one after the other, from the beginning of a project to the functional completion and shipping of the product. A central characteristic of the sprint is its cyclical nature. There are four processes within a sprint, 1) the goal or identifying the requirements and features to be developed; 2) completion and acceptance of the features and requirements; 3) review by the stakeholders of the completed requirements; 4) an honest review of the sprint with a discussion on how to adapt if necessary.

Within each sprint, the development group builds and tests a functional part of the software product until the business owner or stakeholder accepts it. At that time the functionality focus of that particular sprint becomes a viable, shippable product. The whole process is repeated throughout the life of the software development process, so when one sprint finishes, the next sprint starts. Product releases occur at the end of a sprint or after several sprints have completed their cycle.

In previous methods of software development, several phenomenons came into play that impeded the development and completion of software projects. "Scope creep" – also known as feature creep, focus creep, creeping functionality and kitchen-sink syndrome – can sneak up, morph and destroy a project. "Analysis Paralysis" impeded progress when teams tried to develop at the same time they were gathering requirement information. As working groups "sprint" through the development process, at each interval they have time to re-evaluate and if necessary, steer the project in another direction.

A sprint approach empowers teams to continuously revisit and change course when needed. The software product is optimized throughout its development, preserving its critical elements and market relevance. Once the development team concludes the sprint, the product that was the focus of that particular sprint has been developed, tested, integrated, and documented.

The web is a fast-moving environment. New products and applications are constantly showing up in the marketplace. The sprint aspect of agile development gives you the luxury of taking delivery of your product incrementally on a regularly defined timeline, feature by feature and function by function. It is to your advantage to hear real customer and user feedback prior to building the entire software application. The sprint aspect of agile development works on the principle that requirements evolve and emerge. No matter how much analysis and design you do, requirements have a habit of changing, therefore small usable increments of a product will give you vital information regarding what works or doesn't. For more information on agile development and what a sprint will mean to your project,contact us.