https://www.webneticsuk.com/forum/ Sun, 12 Apr 2026 09:20:46 +0000 MyBB https://www.webneticsuk.com/forum/showthread.php?tid=205 Sun, 27 Mar 2011 12:32:30 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=205 Common rules

1. Only one account per person is permitted.
2. Do not pretend to be/represent somebody else. Your account will be deleted if found to be in breach of this rule.
3. When registering, a valid email address has to be used. Disposable email addresses are not permitted. If found, we will remove the account in question.
4. Keep all posts on-topic.
5. All posts must be in English, unless posted in a specific international forum. If posting in a international forum, please use the language of that forum, and not English.
6. DO NOT SEND SUPPORT REQUESTS VIA PM, unless expressly invited to do so. Using PM to actively solicit work is not allowed. Post, in accord with the rules in the correct forum. Abuse of the PM system in this way can lead to your membership being removed.
7. Do not discuss illegal activities.
8. No useless posts. This includes: Thread bumping, useless one liners, repeated requests about new versions, Flamewars, Trolling and Spamming.
9. Do not propose/link to any site that contains warez/copyrighted software/materials that can be downloaded illegally.
10. Do not link to any site that contains adult content, sexually oriented material or might otherwise be considered offensive. Any post containing an inappropriate link will be deleted and the poster will receive a warning.

At all times

1. Keep all commentary civil, and be courteous at all times. Constructive criticism is welcome, but insults directed towards other users or the site admins will not be tolerated. Coarse/insulting language will not be tolerated.
2. Choose an appropriate subject line. Try to summarise the problem briefly in the subject, and elaborate in the message itself. A title like "Have you seen this..." or "Help needed!!!!" will be deleted.
3. Spend 10 minutes with the admin panel before posting common sense questions like "How do I see orders", or "How do I add products". If you go through each admin menu you will find all you need to know about the basic features.
4. Search before posting. You may need to search multiple variation of the terms.
5. Any posts deemed to be self promotion, advertising, or spam can and will be removed. NO SPAM - NO ADVERTISING eg. Posting and making excessive, inappropriate and unnecessary references to your products and websites is self promotion.
6. Don't lump sum mods and inquiries in one post. People asking for help and at the same time attaching a contribution should be avoided. Contributions go in the contrib thread. Help goes in one of the support threads, based on the affected element (modules, templates, languages, general, etc).
7. Bugs go into the bug area ONLY after you have searched the bug forum and found nothing similar.
8. Hijacking threads because you feel the need to whine or complain about your personal opinions that have nothing to do with the main topic of the thread will be instantly deleted at will!
9. If you feel a post violates any of these rules, or you need to bring it to the attention of a moderator (move threads/close/split), please use the ‘report this post’ link to notify the moderators.

Signatures & Avatars

1. Must be setup in your Profile (user Control Panel) , and not manually added to your messages.
2. May not contain any pricing, sales, product etc. details.
3. Only exact URLs allowed ie not LOOK HERE - No tinyurls, affiliate links etc either, only exact, literal URLs
4. Maximum font size should not be larger than normal +1.
5. Signature shall not have more than 4 lines (at a line width of 75 chars).
6. Any signature or avatar that is offensive or insulting to either us, our members, or our staff, is prohibited.
7. Signature size should not exceed the maximum size of 60 x 180 px (height x width).
8. Avatar size should not exceed the maximum size of 75 x 75 px (height x width).
9. Signature & Avatar images may not contain any copyright material (e.g. trademarks)
10. We reserve the right to ask you to change and/or remove your signature or avatar at any time, for any reason.

Failure to abide by these rules may result in an editing, negative moderation or deletion of your post.
We reserve the right to ban users from the site.
We reserve the right to change these rules at any time.]]> Common rules

1. Only one account per person is permitted.
2. Do not pretend to be/represent somebody else. Your account will be deleted if found to be in breach of this rule.
3. When registering, a valid email address has to be used. Disposable email addresses are not permitted. If found, we will remove the account in question.
4. Keep all posts on-topic.
5. All posts must be in English, unless posted in a specific international forum. If posting in a international forum, please use the language of that forum, and not English.
6. DO NOT SEND SUPPORT REQUESTS VIA PM, unless expressly invited to do so. Using PM to actively solicit work is not allowed. Post, in accord with the rules in the correct forum. Abuse of the PM system in this way can lead to your membership being removed.
7. Do not discuss illegal activities.
8. No useless posts. This includes: Thread bumping, useless one liners, repeated requests about new versions, Flamewars, Trolling and Spamming.
9. Do not propose/link to any site that contains warez/copyrighted software/materials that can be downloaded illegally.
10. Do not link to any site that contains adult content, sexually oriented material or might otherwise be considered offensive. Any post containing an inappropriate link will be deleted and the poster will receive a warning.

At all times

1. Keep all commentary civil, and be courteous at all times. Constructive criticism is welcome, but insults directed towards other users or the site admins will not be tolerated. Coarse/insulting language will not be tolerated.
2. Choose an appropriate subject line. Try to summarise the problem briefly in the subject, and elaborate in the message itself. A title like "Have you seen this..." or "Help needed!!!!" will be deleted.
3. Spend 10 minutes with the admin panel before posting common sense questions like "How do I see orders", or "How do I add products". If you go through each admin menu you will find all you need to know about the basic features.
4. Search before posting. You may need to search multiple variation of the terms.
5. Any posts deemed to be self promotion, advertising, or spam can and will be removed. NO SPAM - NO ADVERTISING eg. Posting and making excessive, inappropriate and unnecessary references to your products and websites is self promotion.
6. Don't lump sum mods and inquiries in one post. People asking for help and at the same time attaching a contribution should be avoided. Contributions go in the contrib thread. Help goes in one of the support threads, based on the affected element (modules, templates, languages, general, etc).
7. Bugs go into the bug area ONLY after you have searched the bug forum and found nothing similar.
8. Hijacking threads because you feel the need to whine or complain about your personal opinions that have nothing to do with the main topic of the thread will be instantly deleted at will!
9. If you feel a post violates any of these rules, or you need to bring it to the attention of a moderator (move threads/close/split), please use the ‘report this post’ link to notify the moderators.

Signatures & Avatars

1. Must be setup in your Profile (user Control Panel) , and not manually added to your messages.
2. May not contain any pricing, sales, product etc. details.
3. Only exact URLs allowed ie not LOOK HERE - No tinyurls, affiliate links etc either, only exact, literal URLs
4. Maximum font size should not be larger than normal +1.
5. Signature shall not have more than 4 lines (at a line width of 75 chars).
6. Any signature or avatar that is offensive or insulting to either us, our members, or our staff, is prohibited.
7. Signature size should not exceed the maximum size of 60 x 180 px (height x width).
8. Avatar size should not exceed the maximum size of 75 x 75 px (height x width).
9. Signature & Avatar images may not contain any copyright material (e.g. trademarks)
10. We reserve the right to ask you to change and/or remove your signature or avatar at any time, for any reason.

Failure to abide by these rules may result in an editing, negative moderation or deletion of your post.
We reserve the right to ban users from the site.
We reserve the right to change these rules at any time.]]> https://www.webneticsuk.com/forum/showthread.php?tid=155 Mon, 05 Jan 2009 20:47:45 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=155
Vertically or Horizontally?

Essentially it depends on your site design, sites such as Digg which include the login form in the header often choose a horizontal login form to compact the form in as little space as possible.

Digg use a horizontal login form which appears when the user selects the 'Login' link, interestingly this can provoke a warning from Internet security software which may not be ideal for compatibility.

Other sites which place the login form in the page body often choose the vertical approach.

MySpace uses a vertical login form which includes a 'Remember Me' option for returning visitors.

Remember Me?

Some sites include 'Remember Me' options enabling the login system to automatically remember and log the user in when they next visit. Sometimes this will simply mean the login system remembers the username, or some remember the password and entirely skip the login form.

Facebook's login form includes a 'Remember Me' option for returning visitors.

PayPal's login form does not include a 'Remember Me' option, this is clearly to avoid accidental security breaches.

Windows Live offers the choice, enabling the user to choose whether the system should remember their username, or their username and password.

The overal concensus seems to be a question of security, sites such as YouTube which do not store confidential data automatically remember the user for convenience. Sites such as PayPal where security is of major concern do not offer any option to remember login details and in fact, PayPal employs an extremely strict sessions system to avoid session hijacking.

Username or Email Address?

Should a login form request a username and password, or an email address and password? This is usually a question of preference and ultimately the best option is to give the user the choice. More secure login systems, such as online banking login systems require the user enter only selected characters from their password. This is a fantastic security method which prevents key loggers from being used to gather login details, or from malicious individuals from monitoring internet connections to collect the details.

Natwest's Online Banking system requires you enter three characters from your password and pin code, the required characters are chosen at random. This of course only reduces the risk of occassional key logging, if someone were to continually monitor the same user for an extended period of time they could gather the login credentials in the same way, but this login method does offer protection for the user when using insecure computers on occassion.]]>
Vertically or Horizontally?

Essentially it depends on your site design, sites such as Digg which include the login form in the header often choose a horizontal login form to compact the form in as little space as possible.

Digg use a horizontal login form which appears when the user selects the 'Login' link, interestingly this can provoke a warning from Internet security software which may not be ideal for compatibility.

Other sites which place the login form in the page body often choose the vertical approach.

MySpace uses a vertical login form which includes a 'Remember Me' option for returning visitors.

Remember Me?

Some sites include 'Remember Me' options enabling the login system to automatically remember and log the user in when they next visit. Sometimes this will simply mean the login system remembers the username, or some remember the password and entirely skip the login form.

Facebook's login form includes a 'Remember Me' option for returning visitors.

PayPal's login form does not include a 'Remember Me' option, this is clearly to avoid accidental security breaches.

Windows Live offers the choice, enabling the user to choose whether the system should remember their username, or their username and password.

The overal concensus seems to be a question of security, sites such as YouTube which do not store confidential data automatically remember the user for convenience. Sites such as PayPal where security is of major concern do not offer any option to remember login details and in fact, PayPal employs an extremely strict sessions system to avoid session hijacking.

Username or Email Address?

Should a login form request a username and password, or an email address and password? This is usually a question of preference and ultimately the best option is to give the user the choice. More secure login systems, such as online banking login systems require the user enter only selected characters from their password. This is a fantastic security method which prevents key loggers from being used to gather login details, or from malicious individuals from monitoring internet connections to collect the details.

Natwest's Online Banking system requires you enter three characters from your password and pin code, the required characters are chosen at random. This of course only reduces the risk of occassional key logging, if someone were to continually monitor the same user for an extended period of time they could gather the login credentials in the same way, but this login method does offer protection for the user when using insecure computers on occassion.]]> https://www.webneticsuk.com/forum/showthread.php?tid=119 Sat, 06 Sep 2008 10:29:01 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=119
Preparation: Make sure a creative schedule is supplied, containing vital information such as banner dimensions, placements and the all-important file sizes. Without this information we could be designing a banner that doesn't meet the client's requirements and end up wasting valuable time and money.

Communication: Some of our clients have high expectations for the banner; video and sound are common requests. It's up to us to explain that their expectations may be unrealistic. It's all about guiding the client in the right direction for the job ahead and setting boundaries for what can be achieved within the spec.

Design: There are no hard and fast rules when it comes to designing a 30K banner. We can design a simplistic banner with no images, no gradients and no animations and still produce top quality work. It's all about knowing the limits and using things sparingly.

Plan the movie: Planning out our movie will give you a better idea of all the different elements required to complete the job. Knowing your key library symbols will save you from repeating or perhaps uploading more symbols than required. We also keep symbols in the library to a minimum and try to reuse as many as possible.

Fonts: Even the number of different fonts and font styles you use can have an effect on file size, so use them wisely. When embedding fonts, we try and use characters that we need rather than the whole font family.

Images: When using images, keep them to what's absolutely necessary to complete the job. Having one or two good-quality images is better than having four poor ones. Optimising our images in a separate application before importing them to Flash is valuable: if we can take a few K off by reducing the colours, and so on, then every little bit helps. Flash does give you the option to optimise your images further; do this by right-clicking the image, going to Properties, and here you'll see the

Compression option. When importing the image into your library, we try to make them the exact maximum physical size we require. It wastes valuable K when you bring in an image that's bigger than what's needed. Sometimes we can get a better result by converting our bitmap image into a vector; however this isn't always the case depending on the image detail, so it's one to try and test.

Components: In general, the fewer the components you have, the smaller the file size. Therefore, we only keep essentials in the library. I mentioned before how it helps to know how many movie clips, and so on, you have and how to reuse them. When you reuse a symbol, it doesn't increase the file size because you're just reusing the same item over and over.

Frames: Reducing the number of frames in our movie will also help. Using ActionScript to replace vast numbers of frames is a great way to do this.
A perfect example is using ActionScript to hold your banner at a certain point for a period of time rather than inserting more frames to be played out.

Testing: An absolute must when building a banner to a small file size is testing. When previewing your banner, select BandwidthProfiler. This will show information such as the frame rate, dimensions and also the current file size. If your banner is sneaking above that vital 30K, we start chipping away; it'll be worth it in the end.

The best advice I can offer is to experiment: use gradients, alphas and images, but use them in moderation. Today we're always being told that too much of anything is a bad thing and this advice should equally be applied to the 30K banner.]]>
Preparation: Make sure a creative schedule is supplied, containing vital information such as banner dimensions, placements and the all-important file sizes. Without this information we could be designing a banner that doesn't meet the client's requirements and end up wasting valuable time and money.

Communication: Some of our clients have high expectations for the banner; video and sound are common requests. It's up to us to explain that their expectations may be unrealistic. It's all about guiding the client in the right direction for the job ahead and setting boundaries for what can be achieved within the spec.

Design: There are no hard and fast rules when it comes to designing a 30K banner. We can design a simplistic banner with no images, no gradients and no animations and still produce top quality work. It's all about knowing the limits and using things sparingly.

Plan the movie: Planning out our movie will give you a better idea of all the different elements required to complete the job. Knowing your key library symbols will save you from repeating or perhaps uploading more symbols than required. We also keep symbols in the library to a minimum and try to reuse as many as possible.

Fonts: Even the number of different fonts and font styles you use can have an effect on file size, so use them wisely. When embedding fonts, we try and use characters that we need rather than the whole font family.

Images: When using images, keep them to what's absolutely necessary to complete the job. Having one or two good-quality images is better than having four poor ones. Optimising our images in a separate application before importing them to Flash is valuable: if we can take a few K off by reducing the colours, and so on, then every little bit helps. Flash does give you the option to optimise your images further; do this by right-clicking the image, going to Properties, and here you'll see the

Compression option. When importing the image into your library, we try to make them the exact maximum physical size we require. It wastes valuable K when you bring in an image that's bigger than what's needed. Sometimes we can get a better result by converting our bitmap image into a vector; however this isn't always the case depending on the image detail, so it's one to try and test.

Components: In general, the fewer the components you have, the smaller the file size. Therefore, we only keep essentials in the library. I mentioned before how it helps to know how many movie clips, and so on, you have and how to reuse them. When you reuse a symbol, it doesn't increase the file size because you're just reusing the same item over and over.

Frames: Reducing the number of frames in our movie will also help. Using ActionScript to replace vast numbers of frames is a great way to do this.
A perfect example is using ActionScript to hold your banner at a certain point for a period of time rather than inserting more frames to be played out.

Testing: An absolute must when building a banner to a small file size is testing. When previewing your banner, select BandwidthProfiler. This will show information such as the frame rate, dimensions and also the current file size. If your banner is sneaking above that vital 30K, we start chipping away; it'll be worth it in the end.

The best advice I can offer is to experiment: use gradients, alphas and images, but use them in moderation. Today we're always being told that too much of anything is a bad thing and this advice should equally be applied to the 30K banner.]]> https://www.webneticsuk.com/forum/showthread.php?tid=91 Thu, 08 May 2008 18:03:05 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=91
We currently use our own in-house software, which has been designed to reflect our own needs. We use this software for planning and delivering the projects to our client’s. Not only that, we use it to make sure everything happens on time and on budget. We try and make sure our client’s are happy.

We try and define, and agree with our client, exactly what the project is — and what it isn't. We always ask key questions before we even think of firing up Dreamweaver. This will help us to build a clear picture of the project and could spare us some headaches later.

These questions may include:

When does it need to be done by?
What do you need it to do?
Who is it aimed at?
How much should it cost?

'Visioning' the project means getting a clear picture of what's expected of us and whether these expectations are realistic. If our client wants a 200-page, multilingual corporate website with a social networking element, linked to a secure payment gateway — and wants it done by next Friday, for 100 pounds — you'll know the vision is unrealistic from the off and you'll need to negotiate. When we work with our clients we try to a agree an achievable project vision, write it all down and get your client to sign up to it.

We like to create a 'project plan' that defines individual tasks, timescales and responsibilities. We always try and refer back to our project notes. If we agreed to deliver an eCommerce site in a month, then using two designers to spend three weeks designing the tabs on the main nav probably isn't wise. It’s best to split the plan into three phases: design, production and testing. Once we our happy with the plan, and our client is happy too, we get them to agree to it. Collect a list of risks at the beginning of the project. Like what happens when something goes wrong and what actions we can take to avoid these risks. At Virtual Web Designs, we like to hold regular meetings to review the progress, looking at where we are against the project plans, any new risks or problems and what needs to happen to keep us on track. This disciplined approach keeps us focused on the project and enables us to make any adjustments to our plan as we go, to keep it realistic and achievable. You must work closely with your client, making sure that they're happy with the way everything's going. We provide our clients with weekly updates on there projects. We use our own project management software. The client will automatically get an email when the plan is updated. This way the client can see every step of there project online in real time.

Letting our clients know where you are against the plan, presenting the work we've done since the last update and — importantly — letting them know what we need from them in the coming week.

Think of the client as another member of the project team, as vital to the success of the project as the designer or developer. Without co-operation from your client, you won't get far. If the client starts to change their mind during the project, it's wise to have a process for handling any changes to your project plan.]]>
We currently use our own in-house software, which has been designed to reflect our own needs. We use this software for planning and delivering the projects to our client’s. Not only that, we use it to make sure everything happens on time and on budget. We try and make sure our client’s are happy.

We try and define, and agree with our client, exactly what the project is — and what it isn't. We always ask key questions before we even think of firing up Dreamweaver. This will help us to build a clear picture of the project and could spare us some headaches later.

These questions may include:

When does it need to be done by?
What do you need it to do?
Who is it aimed at?
How much should it cost?

'Visioning' the project means getting a clear picture of what's expected of us and whether these expectations are realistic. If our client wants a 200-page, multilingual corporate website with a social networking element, linked to a secure payment gateway — and wants it done by next Friday, for 100 pounds — you'll know the vision is unrealistic from the off and you'll need to negotiate. When we work with our clients we try to a agree an achievable project vision, write it all down and get your client to sign up to it.

We like to create a 'project plan' that defines individual tasks, timescales and responsibilities. We always try and refer back to our project notes. If we agreed to deliver an eCommerce site in a month, then using two designers to spend three weeks designing the tabs on the main nav probably isn't wise. It’s best to split the plan into three phases: design, production and testing. Once we our happy with the plan, and our client is happy too, we get them to agree to it. Collect a list of risks at the beginning of the project. Like what happens when something goes wrong and what actions we can take to avoid these risks. At Virtual Web Designs, we like to hold regular meetings to review the progress, looking at where we are against the project plans, any new risks or problems and what needs to happen to keep us on track. This disciplined approach keeps us focused on the project and enables us to make any adjustments to our plan as we go, to keep it realistic and achievable. You must work closely with your client, making sure that they're happy with the way everything's going. We provide our clients with weekly updates on there projects. We use our own project management software. The client will automatically get an email when the plan is updated. This way the client can see every step of there project online in real time.

Letting our clients know where you are against the plan, presenting the work we've done since the last update and — importantly — letting them know what we need from them in the coming week.

Think of the client as another member of the project team, as vital to the success of the project as the designer or developer. Without co-operation from your client, you won't get far. If the client starts to change their mind during the project, it's wise to have a process for handling any changes to your project plan.]]> https://www.webneticsuk.com/forum/showthread.php?tid=90 Thu, 08 May 2008 18:02:06 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=90 Defining Good Design

There are two main standpoints from which most people determine whether a web site design is “good” or “bad.” There’s a strict usability standpoint, which focuses on functionality, the effective presentation of information, and efficiency.

Then there’s the purely aesthetic perspective, which is all about presentation, hot animations, and sexy graphics. Some designers get caught up in the aesthetics and graphics and forget about the user, and some usability gurus get lost in their user testing and forget about visual appeal. In order to reach people and retain their interest, it’s essential to maximize both.

The most important thing to keep in mind is that design is about communication. If you create a web site that works and presents information well, but looks ugly or doesn’t fit with the client’s brand, no one will want to use it. Similarly, if you make a beautiful web site that isn’t usable and accessible, people may not be able to use it. Indeed, the elements and functionality of a finished web site design should work as a single cohesive unit, so that:
Users are pleased by the design but drawn to the content

One of the biggest concerns among usability professionals is the time it takes users to scan the page for the information they want, be it a piece of content, a link to another page, or a form field. The design should not be a hindrance; it should act as a conduit between the user and the information.

Users can move about easily via intuitive navigation

We’ll talk more about the placement of navigation later, but the main navigation block itself should be clearly visible on the page, and each link should have a descriptive title. A navigation structure that not only changes appearance on mouse hover, but also indicates the active page or section, as does the menu shown, helps users recognise where they are, and how to get where they want to go.

Secondary navigation, search fields, and outgoing links should not be dominant features of the page. If we make these items easy to find, and separate them visually from the content, we allow users to focus on the information, though they’ll know where to look when they’re ready to move on to other content.

Users recognise each page as belonging to the site

Even if there’s a dramatic difference between the layout of the homepage and the rest of the site, a cohesive theme or style should exist across all the pages of a site to help hold the design together.]]> Defining Good Design

There are two main standpoints from which most people determine whether a web site design is “good” or “bad.” There’s a strict usability standpoint, which focuses on functionality, the effective presentation of information, and efficiency.

Then there’s the purely aesthetic perspective, which is all about presentation, hot animations, and sexy graphics. Some designers get caught up in the aesthetics and graphics and forget about the user, and some usability gurus get lost in their user testing and forget about visual appeal. In order to reach people and retain their interest, it’s essential to maximize both.

The most important thing to keep in mind is that design is about communication. If you create a web site that works and presents information well, but looks ugly or doesn’t fit with the client’s brand, no one will want to use it. Similarly, if you make a beautiful web site that isn’t usable and accessible, people may not be able to use it. Indeed, the elements and functionality of a finished web site design should work as a single cohesive unit, so that:
Users are pleased by the design but drawn to the content

One of the biggest concerns among usability professionals is the time it takes users to scan the page for the information they want, be it a piece of content, a link to another page, or a form field. The design should not be a hindrance; it should act as a conduit between the user and the information.

Users can move about easily via intuitive navigation

We’ll talk more about the placement of navigation later, but the main navigation block itself should be clearly visible on the page, and each link should have a descriptive title. A navigation structure that not only changes appearance on mouse hover, but also indicates the active page or section, as does the menu shown, helps users recognise where they are, and how to get where they want to go.

Secondary navigation, search fields, and outgoing links should not be dominant features of the page. If we make these items easy to find, and separate them visually from the content, we allow users to focus on the information, though they’ll know where to look when they’re ready to move on to other content.

Users recognise each page as belonging to the site

Even if there’s a dramatic difference between the layout of the homepage and the rest of the site, a cohesive theme or style should exist across all the pages of a site to help hold the design together.]]> https://www.webneticsuk.com/forum/showthread.php?tid=80 Fri, 11 Apr 2008 13:42:48 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=80
What does the company do?
What is your role in the company?
Does the company have an existing logo or brand?
What is your goal in developing a web site?
What information do you wish to provide online?
Who comprises your target audience?
Do its members share any common demographics, like age, sex, or a physical location?
Who are your competitors and do they have web sites?

Sometimes I start off with more questions than those listed here—use your imagination and try to come up with some creative queries that will really give you more insight into the client organisation. If you’re a programmer, avoid the tech jargon. If you’re a designer, avoid talking specifically about design. Sure, that may be all you’re thinking about, but semantic markup, fluid and fixed layouts, and color schemes will likely mean very little to the client. Worse still, these types of conversations can bring misguided design opinions your way even before you get a chance to start thinking about the design yourself.

Implementation

The next step in the design process is to take what you’ve learned from the client and use it to create a design. Regardless of the project, try not to get caught up in the technology associated with building web sites—at least not at first. At this point, it shouldn’t matter whether the site is going to comprise straight HTML, a template for a content management system, or a PHP application; the bottom line is that we have an interface to design and a blank sheet of paper. “Paper?”

That’s right, paper. Did you really think I was going to let you get back to your precious computer right after the client meeting was over? No way.

Here’s why: it’s easy to lose focus on the design if you start thinking about the layout in front of a computer. If you start out on paper, you can ignore the technical limitations of browsers and CSS, and focus on how you want the final product to look. Now you might think that all good designers carry around fancy hardbound sketch books in which they use expensive markers and paint to design masterpiece renderings of web page layouts. For me, the equivalent is a 59p spiral-bound notebook from Asda and any writing instrument I can find on my desk that still works.

I start out by sketching a few possible layouts. After a few of these sketches, I decide on one I like, jump into Fireworks, and use the rectangle tool to block out the areas I’ve marked down on my paper. Once I’ve defined my layout, I experiment with foreground and background colors until I have a solid color scheme. I continue twiddling the Fireworks knobs and pushing around pixels until, finally, I have a comp to show the client.

Simple, right? Okay, perhaps I skipped a few steps in that brief description. Honestly, though, when people ask me how I do what I do, they usually get a similar explanation. The truth is that there are bundles of now-subconscious information from my past experience and those old college design and art classes that have helped me to define my own design process.

Learning how to design is like learning how to program. Some people have a bit of a knack for it, but anyone can learn. Just as there is good code and ugly code, there is good design and ugly design. Learning some of the principles and conventions that are associated with design will help you to understand the difference between the good and the ugly, and help you toward establishing your own design process.

To be continued ….]]>
What does the company do?
What is your role in the company?
Does the company have an existing logo or brand?
What is your goal in developing a web site?
What information do you wish to provide online?
Who comprises your target audience?
Do its members share any common demographics, like age, sex, or a physical location?
Who are your competitors and do they have web sites?

Sometimes I start off with more questions than those listed here—use your imagination and try to come up with some creative queries that will really give you more insight into the client organisation. If you’re a programmer, avoid the tech jargon. If you’re a designer, avoid talking specifically about design. Sure, that may be all you’re thinking about, but semantic markup, fluid and fixed layouts, and color schemes will likely mean very little to the client. Worse still, these types of conversations can bring misguided design opinions your way even before you get a chance to start thinking about the design yourself.

Implementation

The next step in the design process is to take what you’ve learned from the client and use it to create a design. Regardless of the project, try not to get caught up in the technology associated with building web sites—at least not at first. At this point, it shouldn’t matter whether the site is going to comprise straight HTML, a template for a content management system, or a PHP application; the bottom line is that we have an interface to design and a blank sheet of paper. “Paper?”

That’s right, paper. Did you really think I was going to let you get back to your precious computer right after the client meeting was over? No way.

Here’s why: it’s easy to lose focus on the design if you start thinking about the layout in front of a computer. If you start out on paper, you can ignore the technical limitations of browsers and CSS, and focus on how you want the final product to look. Now you might think that all good designers carry around fancy hardbound sketch books in which they use expensive markers and paint to design masterpiece renderings of web page layouts. For me, the equivalent is a 59p spiral-bound notebook from Asda and any writing instrument I can find on my desk that still works.

I start out by sketching a few possible layouts. After a few of these sketches, I decide on one I like, jump into Fireworks, and use the rectangle tool to block out the areas I’ve marked down on my paper. Once I’ve defined my layout, I experiment with foreground and background colors until I have a solid color scheme. I continue twiddling the Fireworks knobs and pushing around pixels until, finally, I have a comp to show the client.

Simple, right? Okay, perhaps I skipped a few steps in that brief description. Honestly, though, when people ask me how I do what I do, they usually get a similar explanation. The truth is that there are bundles of now-subconscious information from my past experience and those old college design and art classes that have helped me to define my own design process.

Learning how to design is like learning how to program. Some people have a bit of a knack for it, but anyone can learn. Just as there is good code and ugly code, there is good design and ugly design. Learning some of the principles and conventions that are associated with design will help you to understand the difference between the good and the ugly, and help you toward establishing your own design process.

To be continued ….]]> https://www.webneticsuk.com/forum/showthread.php?tid=72 Tue, 25 Mar 2008 19:33:12 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=72
For many web developers, myself included, the most intimidating part of the design process is getting started. Imagine for a moment that you’re sitting at your desk with nothing other than a cup of coffee and the business card of a potential client who needs a basic corporate web site.

Usually, a business card speaks volumes about a company’s identity, and could be used as design inspiration.

Unfortunately, that’s not the case with the card for Joe Blogs. It’s black and white, all text, no character. Talk about a blank canvas! So, where do you go from here? You need a plan … and you need to contact Joe Blogs. With some critical input from the client about what his company actually does, and by gathering information about the content you have to work with, you’ll be able to come up with a successful layout and design.

The Design Process

In a web-programming book I read recently, the author introduced a fictional scenario to explain why readers needed to design a page layout and create a style sheet for the example application. He basically said that the company web designer was off getting inspiration from somewhere and wouldn’t be back until later in the year. It sounded as if he was implying that designers are prone to flake out and go on vision quests for months at a time, but I’m going to assume the author made that comment in an endearing way, and introduce the same scenario.

Here are the hypothetical details of this scenario: Joe Blogs of Blogs Services needs a web site. We have his business card and he’s eager to get started. Unfortunately, the designer is out of town … wait, that’s not a good excuse. Let’s say he was injured during a freak dairy cow stampede while attending the South by South West Interactive (SXSWi) festival in Austin, Texas. Yeah, that’s believable. Anyway, he’s out for a few months, and you’re on your own. So where do you start? The actual process of developing an entire site or web application includes a lot of steps, but the process of creating a design comp boils down to only two tasks: discovery and implementation.

Discovery

The discovery component of the design process is about meeting the clients and discovering what they do. This may not feel like a “designy” task, but gathering information about who your clients are and how they run their business is the only way you’ll be able to come up with an appropriate and effective design.

Before you schedule your first meeting with your clients, take a few minutes to figure out what they do and how they do it. If they’ve asked you to design a web site for them, they may not currently have one, but Google them anyway. If you can’t find any information about their business specifically, try to learn a little more about their industry before the first meeting. Whenever possible, the first meeting with a client should be an actual person-to-person meeting. Sometimes, distance will dictate that the initial meeting will occur over the phone or via email, but if the client is in town, schedule a time to meet.

Keep in mind that this meeting isn’t about impressing the client, selling yourself, or selling a web site. The initial client meeting is about communication. Try to listen more than you speak, and bring a pad of paper on which you can make notes. Do not bring a laptop. Computers have screens, and people tend to stare at them. If the client isn’t staring at the screen the whole time, you will be as you write your notes. If you must drag some technology into the meeting, bring a voice recorder. In my experience, though, a pad of paper is less threatening to the often not-so-tech-savvy client.

To be continued …]]>
For many web developers, myself included, the most intimidating part of the design process is getting started. Imagine for a moment that you’re sitting at your desk with nothing other than a cup of coffee and the business card of a potential client who needs a basic corporate web site.

Usually, a business card speaks volumes about a company’s identity, and could be used as design inspiration.

Unfortunately, that’s not the case with the card for Joe Blogs. It’s black and white, all text, no character. Talk about a blank canvas! So, where do you go from here? You need a plan … and you need to contact Joe Blogs. With some critical input from the client about what his company actually does, and by gathering information about the content you have to work with, you’ll be able to come up with a successful layout and design.

The Design Process

In a web-programming book I read recently, the author introduced a fictional scenario to explain why readers needed to design a page layout and create a style sheet for the example application. He basically said that the company web designer was off getting inspiration from somewhere and wouldn’t be back until later in the year. It sounded as if he was implying that designers are prone to flake out and go on vision quests for months at a time, but I’m going to assume the author made that comment in an endearing way, and introduce the same scenario.

Here are the hypothetical details of this scenario: Joe Blogs of Blogs Services needs a web site. We have his business card and he’s eager to get started. Unfortunately, the designer is out of town … wait, that’s not a good excuse. Let’s say he was injured during a freak dairy cow stampede while attending the South by South West Interactive (SXSWi) festival in Austin, Texas. Yeah, that’s believable. Anyway, he’s out for a few months, and you’re on your own. So where do you start? The actual process of developing an entire site or web application includes a lot of steps, but the process of creating a design comp boils down to only two tasks: discovery and implementation.

Discovery

The discovery component of the design process is about meeting the clients and discovering what they do. This may not feel like a “designy” task, but gathering information about who your clients are and how they run their business is the only way you’ll be able to come up with an appropriate and effective design.

Before you schedule your first meeting with your clients, take a few minutes to figure out what they do and how they do it. If they’ve asked you to design a web site for them, they may not currently have one, but Google them anyway. If you can’t find any information about their business specifically, try to learn a little more about their industry before the first meeting. Whenever possible, the first meeting with a client should be an actual person-to-person meeting. Sometimes, distance will dictate that the initial meeting will occur over the phone or via email, but if the client is in town, schedule a time to meet.

Keep in mind that this meeting isn’t about impressing the client, selling yourself, or selling a web site. The initial client meeting is about communication. Try to listen more than you speak, and bring a pad of paper on which you can make notes. Do not bring a laptop. Computers have screens, and people tend to stare at them. If the client isn’t staring at the screen the whole time, you will be as you write your notes. If you must drag some technology into the meeting, bring a voice recorder. In my experience, though, a pad of paper is less threatening to the often not-so-tech-savvy client.

To be continued …]]> https://www.webneticsuk.com/forum/showthread.php?tid=22 Wed, 09 Jan 2008 14:14:51 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=22
I'd forgotten this until I got to play around with an iPhone. The web browsing experience on this object of desire is incredibly reminiscent of the ancient machines I used in the record library in Norwich. Scrolling, zooming in, reading, zooming out, scrolling, zooming in, reading some more and so on. I couldn't help thinking that this approach to internet consumption on a handheld device is actually a step backwards. Side scroll is a cardinal sin, right? If so, then "pogoing" in and out ought to be, too.

Please don't get me wrong. I love the fact that our mobile handsets are now net connected. It's great for pub quizzes, for one thing.

However, as things stand, there are only a few people populating the mobile internet that really "get it". These are forward-thinking brands that are developing sites aimed at a mobile audience — where they're not simply trying to replicate, or even transcode, an existing website onto mobile devices. It's services like these that represent the birth of the true mobile internet. They differentiate themselves from a desk-based web experience and truly provide what mobile users are looking for.

Let me try to put this into perspective. When it comes to the internet, the only things our phone browsers share with desk-based browsers are the protocols for delivering data. So, to be successful with a site intended for a mobile audience, it's important to recognise the fundamental differences. Dealing with the obvious items first: mobile browsers have smaller screens, they lack a true mouse and pointer, and the navigation is limited to vertical link selection on all but the higher-end handsets.

This dramatically affects the way mobile users interact with an internet site. A page layout that suits a login screen isn't going to translate to something that feels comfortable on a handset. Visibility is important, and on a mobile device, the limited screen space enforces a typically vertical navigation experience. It's essential to weigh the important and relevant content towards the upper part of the page. When the physical differences are taken care of, the issue of what users actually want should be considered. Once again, looking at the differences between a mobile internet experience and that of a web-based browser should be carefully considered.

Mobile users are typically "on the go" and therefore time limited. With this in mind, you should expect a visitor to be more demanding regarding how quickly they can locate and consume information. Desk-based visitors are more forgiving and likely to browse "off track" as the opportunity arises, but expect a mobile visitor to bounce quickly if you're not providing a streamlined experience.

To create an engaging mobile site, you should consider why a visitor has arrived and what they're looking for. If you think about it, you'll realise that it's often quite different to why a web browser might arrive. If I'm on a bus and I visit sky.com on my mobile, you can bet it's because I want to find out what's on TV tonight — not that I give two hoots about a free dish installation offer or the latest celebrity gossip.

The above distinctions can be the make or break of a successful mobile internet site, but they're not the only rules. If I was to suggest one thing to think about above all else, it would be this: think of the mobile experience as one that's totally separate from the desk-based internet — sharing elements and back-end functionality, yet not structure and not necessarily purpose.]]>
I'd forgotten this until I got to play around with an iPhone. The web browsing experience on this object of desire is incredibly reminiscent of the ancient machines I used in the record library in Norwich. Scrolling, zooming in, reading, zooming out, scrolling, zooming in, reading some more and so on. I couldn't help thinking that this approach to internet consumption on a handheld device is actually a step backwards. Side scroll is a cardinal sin, right? If so, then "pogoing" in and out ought to be, too.

Please don't get me wrong. I love the fact that our mobile handsets are now net connected. It's great for pub quizzes, for one thing.

However, as things stand, there are only a few people populating the mobile internet that really "get it". These are forward-thinking brands that are developing sites aimed at a mobile audience — where they're not simply trying to replicate, or even transcode, an existing website onto mobile devices. It's services like these that represent the birth of the true mobile internet. They differentiate themselves from a desk-based web experience and truly provide what mobile users are looking for.

Let me try to put this into perspective. When it comes to the internet, the only things our phone browsers share with desk-based browsers are the protocols for delivering data. So, to be successful with a site intended for a mobile audience, it's important to recognise the fundamental differences. Dealing with the obvious items first: mobile browsers have smaller screens, they lack a true mouse and pointer, and the navigation is limited to vertical link selection on all but the higher-end handsets.

This dramatically affects the way mobile users interact with an internet site. A page layout that suits a login screen isn't going to translate to something that feels comfortable on a handset. Visibility is important, and on a mobile device, the limited screen space enforces a typically vertical navigation experience. It's essential to weigh the important and relevant content towards the upper part of the page. When the physical differences are taken care of, the issue of what users actually want should be considered. Once again, looking at the differences between a mobile internet experience and that of a web-based browser should be carefully considered.

Mobile users are typically "on the go" and therefore time limited. With this in mind, you should expect a visitor to be more demanding regarding how quickly they can locate and consume information. Desk-based visitors are more forgiving and likely to browse "off track" as the opportunity arises, but expect a mobile visitor to bounce quickly if you're not providing a streamlined experience.

To create an engaging mobile site, you should consider why a visitor has arrived and what they're looking for. If you think about it, you'll realise that it's often quite different to why a web browser might arrive. If I'm on a bus and I visit sky.com on my mobile, you can bet it's because I want to find out what's on TV tonight — not that I give two hoots about a free dish installation offer or the latest celebrity gossip.

The above distinctions can be the make or break of a successful mobile internet site, but they're not the only rules. If I was to suggest one thing to think about above all else, it would be this: think of the mobile experience as one that's totally separate from the desk-based internet — sharing elements and back-end functionality, yet not structure and not necessarily purpose.]]> https://www.webneticsuk.com/forum/showthread.php?tid=7 Mon, 26 Nov 2007 20:50:54 +0000 webnetics]]> https://www.webneticsuk.com/forum/showthread.php?tid=7
“Abstract- W3C

This specification defines the 5th major revision of the core language of the World Wide Web, HTML. In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability. “

Also of note regarding the new Working Group Charter is the unprecedented requirement that it's open to anyone interested in contributing to the process. Microsoft's Chris Witson (product manager of IE) and the W3C's Dan Connolly chair the Working Group, which contains representatives from major browser vendors and W3C members, as well as a host of independent developers. It's open to anyone, so if you have strong feelings about the direction the group is taking, you can subscribe to the mailing list and get involved.

Why do we need HTML 5?

HTML is the lingua franca of the web — without it, there would be nothing. The W3C decided some years ago that the future of the web was XML, and put together a group to work on XHTML — a reformulation of HTML as XML. Initially popular among developers, XHTML has been leading a charmed life. Browser makers haven't embraced it: IE in particular doesn't support XHTML documents served with the application/xhtml+xml MIME type, so any XHTML documents sent to it are treated as normal HTML and the advantages that XHTML is supposed to bring are not evident.

The long-term future of XHTML isn't clear. XHTML 2, now in working draft, is controversial because it's not backward-compatible. It's a new markup language that cannot be used in any current browsers, and many see it as irrelevant.

The W3C has now come to the same conclusion as the WHATWG: it's necessary to develop HTML alongside XHTML. Work on XHTML hasn't stopped, but is running parallel to the development of HTML-- the language that developers need today.

We can expect many new features in HTML 5.

Notable are the new block-level elements: section, header, footer, nay and article. These enable authors to mark up documents with more structure than with non-semantic div elements. There's also a host of new semantic inline elements, including time, meter and progress. All these are improving HTML in an incremental, backward-compatible way.

They degrade gracefully in today's browsers, and move HTML forward from its roots as a scientific document markup language.

More controversial is the inclusion of numerous presentational elements, such as i and b. The theory is that if these elements were not included in browser implementations, less knowledgeable authors would abuse elements such as strong and em to give presentational effects when they should be used as semantic devices.

Of course, what's exciting about the new HTML WG is that if you don't think these presentational elements should be in HTML 5, or you're desperate for some feature you think everyone has forgotten about, you're free to join the Working Group and get involved in the discussion. This is a significant step for the W3C to make, and I believe it's the right one. We're used to listening to people complain about the closed decision-making process that has historically gone on inside the W3C. Now I point these people in the direction of the sign-up forms: stop moaning and do something about it.

For more information on this please visit http://www.w3.org/html/wg/html5/ when you can subscribe to there newsletter or make comments about this.]]>
“Abstract- W3C

This specification defines the 5th major revision of the core language of the World Wide Web, HTML. In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability. “

Also of note regarding the new Working Group Charter is the unprecedented requirement that it's open to anyone interested in contributing to the process. Microsoft's Chris Witson (product manager of IE) and the W3C's Dan Connolly chair the Working Group, which contains representatives from major browser vendors and W3C members, as well as a host of independent developers. It's open to anyone, so if you have strong feelings about the direction the group is taking, you can subscribe to the mailing list and get involved.

Why do we need HTML 5?

HTML is the lingua franca of the web — without it, there would be nothing. The W3C decided some years ago that the future of the web was XML, and put together a group to work on XHTML — a reformulation of HTML as XML. Initially popular among developers, XHTML has been leading a charmed life. Browser makers haven't embraced it: IE in particular doesn't support XHTML documents served with the application/xhtml+xml MIME type, so any XHTML documents sent to it are treated as normal HTML and the advantages that XHTML is supposed to bring are not evident.

The long-term future of XHTML isn't clear. XHTML 2, now in working draft, is controversial because it's not backward-compatible. It's a new markup language that cannot be used in any current browsers, and many see it as irrelevant.

The W3C has now come to the same conclusion as the WHATWG: it's necessary to develop HTML alongside XHTML. Work on XHTML hasn't stopped, but is running parallel to the development of HTML-- the language that developers need today.

We can expect many new features in HTML 5.

Notable are the new block-level elements: section, header, footer, nay and article. These enable authors to mark up documents with more structure than with non-semantic div elements. There's also a host of new semantic inline elements, including time, meter and progress. All these are improving HTML in an incremental, backward-compatible way.

They degrade gracefully in today's browsers, and move HTML forward from its roots as a scientific document markup language.

More controversial is the inclusion of numerous presentational elements, such as i and b. The theory is that if these elements were not included in browser implementations, less knowledgeable authors would abuse elements such as strong and em to give presentational effects when they should be used as semantic devices.

Of course, what's exciting about the new HTML WG is that if you don't think these presentational elements should be in HTML 5, or you're desperate for some feature you think everyone has forgotten about, you're free to join the Working Group and get involved in the discussion. This is a significant step for the W3C to make, and I believe it's the right one. We're used to listening to people complain about the closed decision-making process that has historically gone on inside the W3C. Now I point these people in the direction of the sign-up forms: stop moaning and do something about it.

For more information on this please visit http://www.w3.org/html/wg/html5/ when you can subscribe to there newsletter or make comments about this.]]>