Requesting your Background Checks

I read an interesting article here that I felt compelled to respond to --

Beth Gilfeather's blog, The Candidate Advantage.

Great Article!

It is however unfortunate that such background checks are made -- the last company I worked for did a background check into Interpol, the International Police.

I requested the paperwork (as you have every right to request any background check done on you) so that I could actually see what sort of response and stories were reported about me.

No records came up --

Luckily in the web world, one is most often judged by the work they create. And, while most political laws that governed high school also govern the office, a person's past will show in the work they have created.

Good work which communicates a message -- buying, clicking, searching, learning -- is recognized instinctively -- a point which may elude some.

Dirt and rumors (and background checks) sometimes do not fully describe the truth of why someone was let go. Very often it is the pursuit of truth that leads one to be let go.

Think of how many sexual harassment cases occur reported or unreported in the workplace? Does this make one less desirable to hire because they harass workers?

Probably.

What about someone that hoards pencils and steals from the office supply closet? Are they fit to be hired?

Every job I've ever worked came to exist because of a close connection. No one wants to be humiliated, hurt, or slandered, and sometimes the truth is so good that it must be saved for a book, a play, and a movie.

Captain Gingerbeard once told me that being a programmer is not about solving problems, but it is rather about solving the perception of the problem.

If you see a skeleton from one angle, it just might be an angel in disguise.

Now where was I . . .?

i!

Consider the Concept of Research

Many clients and executive level managers, CEOs, CFOs, etc will most likely want to know what you are doing with your time when it comes to their project. Very often is the case that your suggested timeline/scope will be chopped down, and you will be under pressure to get your project done correctly, and out the door.

As soon as an honest scope time line is chopped down, the first thing to go is the discovery or research of the project.

While this will not shut down the project at the onset, cutting out the research portion of the time line will ultimately result in undisciplined choices to be made down the line which lead to more time being put into the project to untangle the mess that was created because the research phase was ignored.

During the research phase, the entire time line can be broken down into mini phases, lists of page builds and urls can be gathered -- it is an essential part of a project because it allows and prevents workers from doing research when it comes time for them to actually do the work.

When there is no research phase, the workers on the project (designers, developers, etc) spend time on this anyway because in order for someone to understand a project, they must see how it was built, make a plan to build/alter it, and then actually build it.

After building comes testing and perfecting -- as long as the original scope does not change -- so -- leaders of the free world, when your team presents you with a project timeline that you think is too long, just because you think it is too long, take a breath and consider the concept of research.

Sun-Tzu's Art of War

If you are looking for a good book, I highly recommend Sun Tzu's The Art of War.

Front End Development Course Structure

Course II: Front End Development for the Web
HTML, CSS, JavaScript, Preparing Graphics for Mark-up, Web Standards, Best Practices, Search Engine Code and Tracking
Required Tools for Each Student

* Laptop or Desktop Computer capable of running a current version of Photoshop
* Notebook for sketching and notetaking
* Crayons or colored pencils or markers (or all of the above)
* Internet Connection
* Scanner

This course is designed to give the student an introduction to Front End Web Development principles, concepts, patterns and workflow.

Students will complete Front End Web Development projects to increase their understanding of the Front End Development process.

Course culminates in full portfolio review and can be tailored as a 10 - 12 week course.

It is recommended that students have some Web Design knowledge, as covered in the Web Design Concepts Course

* Prepping images for Front End Development
* Learn HTML
* Learn HTML and CSS
* Learn how to work with JavaScript, jquery, Prototype and other JavaScript libraries
* Setting up a Front End Developer work environment
* Critiqing Work
* Dealing with Changes
* Saving organized files and file types

Front End Development Projects

Each project builds on the previous example.

* Preparing images for Development
* Creating HTML - Document Strucutre
* Creating CSS - Document Structure
* SEO - Coding for Search Engines
* Coding Emails - Using Table Code
* Tracking - Working with Tracking Code
* Developing a full scale website

Front End Development Project Details:

*
Preparing graphics for Development

Students will prepare graphics for Front End Web Development.
Coding HTML

Students will learn how to code HTML
Coding HTML using CSS

Students will learn how to code HTML and CSS.
SEO

Students will learn how to code for Search Engines.
Coding for older systems - Table Code

Students will build HTML and CSS code for legacy systems.
Tracking Code

Students will learn how to implement tracking code.
Full Site Front End Development

Students will complete Front End Development on a full scale website. PHP includes will be introduced.

Final Critique

All of the students work will be reviewed.

Design Structure

Ian Scheller Web Course Detail

Course 1: Web Design Principles and Web Design Workflow
2-D Design Concepts, Photoshop, Wireframing, File Types, Designing for the Web

Read the outline below.

Required Tools for Each Student

Laptop or Desktop Computer capable of running a current version of Photoshop
Notebook for sketching and notetaking
Crayons or colored pencils or markers (or all of the above)
Internet Connection
Scanner


This course is designed to give the student an introduction to web design principles, concepts, patterns and workflow.
Students will complete web design projects to increase their understanding of the web design process.
Course culminates in full portfolio review and can be tailored as a 10 - 12 week course.


Learn Basic Design Principles
Learn Photoshop for the web
Learn the phases of design (and how they fit into the bigger production framework)
Critiqing Work
Dealing with Changes
Saving organized files and file types


Design Projects
Each project builds on the previous example.


Buttons and Banners
Animated Buttons and Banners
Wire-Framing
Splash Page (header body footer)
Mini-Site
Full Site


Design Project Details:

Buttons and Banners
Students will create button and banner sets.

Popular Button Sizes


120x90
120x60
88x31
125x125
Custom

Popular Banner Sizes


Horizontal
468x60
392x72
234x60
+++
Vertical
120x240
160x600
Custom

Animated Buttons and Banners
Students will learn how to animate the static banners they created.

Wire-Frames
Students will learn how to wireframe web layouts

Splash Page Design
Students will learn how to design a splash page using web 5.0 concepts.

Mini-Site Design
Students will build off of the Splash page project and turn it into a 3 page mini-site.

Full Site Design
Students will increase the size of their mini-site project into a full fledged website.

Final Critique
All of the students work will be reviewed.

Course Structures

Course I
Web Design Principles and Web Design Workflow

Course II
Front End Developing for the Web and Preparing Files for programming

Course III
Design, Front End Development and Back-End Concepts: Building a good website

Assistant Producers and Producers

A few entries ago, I made the suggestion that Marketing workers should become assistant producers.

I mention this because the existing power struggle between Production and Marketing departments are the cause of a great rift within the web industry.

Some argue that titles do not effect the actual job performance of one's post, however I am suggesting more than a name change.

Typically, the Production department works with the hands on activation of the project.
The physical work of building a web project -- design, development, programming and publishing is a production responsibility.

For some reason, everything else that pertains to the project -- the clients whims, for example are watched over by a completely different department.

Immediately this is a problem.

The physical placement of the web team can have a direct effect on the outcome of the project. With ever changing client wishes, it is imperative to keep the team as close as possible.

Second, every marketing team I've come across is completely ignorant to the actual process and craft of building a website. Also, the production staff is usually ignorant to the actual process that a marketing person must attend to -- endless phone calls and meetings with the client.

Things get even more complicated when either marketing or production is excluded from important meetings on the project.

Because the marketing person is not aware of the web process, they will often make promises on a project they cannot keep.

This again creates problems when the Project Manager on the project is absent because they will miss vital information about the project.

Also, trusting someone that is ill equipped to make intelligent decisions will constantly hurt the creation of your projects.

Why marketing teams are allowed to remain ignorant is a peculiar fact. Most of the people who work in marketing are less computer savvy then their production counterparts. They should be learning about the web process, not excluding their production team.

The old style of Marketing - Production that has been used in traditional business structure does not work here, and as long as Marketing and Production stay opposed to one another, the craft of making successful interactive projects will be continued to be stymied by an outdated business structure and the very people that are charged with working in it.

Bring Marketing and Production together. Make Project Managers Producers, and Marketing Producers Assistant producers.

With a solid team in place, a team that shares knowledge of the web process transparently, greater projects can be more efficiently created.

Own your Name, back up your Files

Own your name and back up your files. These are two very important items to remember even if you have someone else helping your with your website.

You want to be the Administrative Contact on your domain name. If you are not, that usually means someone else is. Several issues arise when someone other then you controls your domain name.

First, if you do not control the name, you might be left sitting on the sideline while someone else does whatever they want with your name. This is problematic for obvious reasons, as your brand and business (and domain name) go hand in hand.

Second, if you are no longer on good terms with your web person, getting your name back can be a very frustrating process.

When you are ordering a new name, make sure to tell your web person to list you as the Administrative Contact for that name. Also have them provide you with the user name and password for the domain registrar's account so that at any time you can have access to the information that is directly related to your name.

If you have control of your domain name, you can have it hosted anywhere you like, and this leaves you open to explore the most cost effective plans for you and your business.

Often is the case that ex-employees, girlfriends, family members and/or weirdos gain control over a domain that is not theirs. To prevent trouble down the road at the very least, be the Administrative Contact on the name. At the very most, own the name, order it yourself, and rest assured you can move that name wherever you want.

Second, ask your web person to provide you with your Hosting user name and password. These are essential items to gain access to your web site as it appears on the web. To take it a step further, you can ask your designer and web person to send you a back-up of the original design files and web files once the project is completed.

Some designers will charge extra when handing over the original build files, so you'll have to work this out. Either way, having a copy of your site backed-up is always a good safety measure in the event you cannot reach your web person, or if you have to switch web people down the road.

Next time, we return to the inside mechanics of the web house.

The Goals of a Web Team

From New York to LA I've had the pleasure of working at a varied group of web companies. Some stuck around, some went the way of the dinosaur, but one thing was constant with all companies. Marketing teams and Production teams did not function hand in hand.

At all companies, Marketing professionals had little or no technical knowledge of how interactive products were built, yet they were the direct line to the client who was ordering the job. Production professionals had all technical knowledge and were put in charge of actually building the project, and delivering it on time.

With these roles in place, an interesting pattern of behavior was identified throughout -- there was real friction between Marketing and Production teams. Communication and the balance of power were (are) unbalanced.

Typically, Production gets easily bothered by Marketing because the Marketing team is speaking to the client with no thought of the technical process. (simply because they don't know what goes into a project) With no thought of the technical process, it is very easy to make empty promises that make the client instantly happy. (on the phone) Unfortunately, when the client is misinformed, the client is rarely called back and explained that the conversation they just had is not completely accurate in regard to the project they are paying good money for. What usually happens is that Production is then put under the gun to deliver under unfair conditions.

It does not have to be unfair, and more importantly friction that is allowed to fester creates bad morale. Bad morale does not help the production of product, and if unchecked will create a high turnover of employees. With high turnover, a solid production style is very difficult to be created and carried out -- especially if a general education or learning process for new hires is not in place. (which it usually isn't)

Before we get too far down a slippery slope of if/then -- it must be noted that any friction between any parties on a project slows -- and sometimes completely halts -- the actual production of a project. Here is my full list of things that stop production:

Things that stop production, in no particular order

1. Arguing
2. Explaining
3. Talking (about something other then the project at hand)
4. Poor Scheduling
5. Non-teamwork/co-worker misunderstanding (uninformed team members)
6. Rush Orders (unless someone is dying, it is not a rush)
7. Non-Emergencies (presented as emergencies)
8. Worry
9. Poor Tools (bad monitor, software, monitor, etc)

Can you identify these items in your chain of production? If so, it is time to eliminate the climate and cause that allows these threats to exist.

The goals of a Web Team should always be creating the best project -- but not at the cost of the company or any members of the company's team -- no matter what part of the team you are on.

Next time -- working out the kinks.

Functioning as a Cohesive Unit

Another simpler term for this is "working together."

Knowing one's role is the only way to excel in one's position within a bigger matrix of production. In order for one to know their role, it is usually a good thing if the larger formalities and structure have a clear role within the larger structures they occupy.

Diagram 1a.

Diagram 1a.

Many web houses or web businesses have no internal teaching for their employees, therefore power struggles will often break out in between departments over non-issues. Each time an internal power struggle breaks out, production of the product is effected.

One of the first items that needs to be addressed with internal web teams is the ego. Most ego problems come from Marketing teams who use second hand knowledge to communicate with the client in regard to their project. Second, most marketing teams sit with marketing teams, where production teams sit with themselves as well.

As with table code, many solutions were created when the web first started because it seemed like the right thing to do. There are many practices that were adopted that serve no purpose in the Line of Production, and actually cause a detriment to the communication within web departments across the board.

If marketing and production teams do not work side by side with the common goal of creating successful projects, then just about all hope will be lost in creating a smooth process.

For Marketing and Production to work side by side requires both teams to humble themselves and work as a true team.

I see production working with the actual craft of the medium and project. Marketing is sometimes a useless step in the process. In diagram 1a. above, the Marketing team becomes assistant producers.

The benefits of this are many, and will be discussed next time.