As a web-based software developer, I have to stay abreast of the latest trends with web standards and, of course, web browsers such as Internet Explorer and Firefox.  The release of Chrome by Google is, in my opinion, a big deal.  What sets Chrome apart from the rest are its features which make it the ultimate web browser for web-based software applications.  These features include:

• Speed, speed, and more speed - The Chrome browser is the fastest browser I've ever used.  Some of the performance may be "perceived", but that doesn't matter to users, so it doesn't matter to me.
• Less, less, and even less - No screen clutter, no bloat, just the basics such as an address bar and area for tabbed browsing take up space, leaving more screen real estate for the web page or application you are browsing.
• The "Make application shortcuts..." function - A cool feature in the page functions dropdown allows you to place a shortcut on your desktop which launches the web page or application in a full window (without an address bar), thus providing even more screen real estate to the web page or application

Let’s face it, users of database software systems often think the best way to manage information is to export it to MS-Excel and play with it there. Or, even worse, just start with a blank spreadsheet and build it out from scratch. Why do users do this? They are looking for an emergent environment to operate within.

What does this mean? It means that software users don’t always want just one button to push in order to perform a complex task. Most often, this is because the user has a special consideration they need to make which the software can’t natively handle. However, and more often than you may think, the software can handle the situation, but because the complexities are handled behind-the-scenes, the end user doesn’t trust the results and would therefore prefer to accomplish the task manually.

Software which provides a strong collection of basic, common functionalities is leveraging the power of emergence. This software doesn’t assume all the complex functions need to be provided. In contrast, it merely provides several smaller functions and allows the user to assemble these smaller parts into the comprehensive task they are wanting. Users like MS-Excel because it presents an emergent, “level playing field” in which untold complex tasks can be assembled in any way that the user sees fit.

This doesn’t mean that the powerful, single button functions are useless; however, the right answer for consolidating complex tasks is the use of “wizards” (aka task dialogs) which guide the user through the process in a step-by-step manner. Even MS-Excel has wizards for performing such tasks. My point is just because you can consolidate a complex task into a single button doesn’t mean you should. The user may be more comfortable if they see the task broken out into a handful of digestable steps in the form of a “wizard” and be less likely to spend undue time dumping the data out to a spreadsheet and performing the task manually.

Wherever you go in the IT marketplace, there are always plenty of acronyms to be had. As a software developer, I have terms such as OOP, AJAX, SQL, and API, which are, for the most part, specific to my role. Now that I’ve re-entered the church/faith-based marketplace, I’ve noticed there are some acronyms missing that I’ve gotten used to hearing from other, non-religious industries, namely SME and SOP.

SME - Subject Matter Expert - Wise management knows better than to make a decision which may impact software usage or business practices without a SME or two in the room. Knowing who your SME’s are also allows you to distribute knowledge to new employees using a “workforce partner” or “train from within” program.

SOP - Standard Operating Procedure - Regardless of how powerful your software and business systems are, they can always be used incorrectly. This is why no software implementation is really complete without a corresponding set of SOP’s which explain the processes involved for using the software to meet the real-world scenarios users will encounter.

I want to encourage churches and faith-based organizations to consider these acronyms and the meanings behind them. As you wrestle with new software solutions or integrating existing software applications, utilizing SME’s and SOP’s will help you make better decisions and distribute standard business practices in your organization.

At the IT Roundtable last week, I asked the gathering of mostly church IT administrators, “How many of you don’t have an intranet?”. I was a bit shocked as most of them raised their hands.

It seems many IT administrators consider an intranet as yet another data store to maintain. From my perspective, this is exactly the opposite of why I think an intranet should exist in any organization of 50 employees or more. The last thing an intranet should do is create an additional place to create new things such as files and additional data.

In my opinion, an intranet should first serve as a read-only hub which ties together all the different database systems into a single, consolidated interface. In a church environment, this means providing interfaces into your member database, events system, and personnel data. Simple searching capabilities should be the goal here. The next level of functionality an intranet should provide is that of simple forms routing (what I call “E-Forms”). Finally, I would suggest making staff-wide documents (such as policies & procedures or other HR documents) available through the intranet. The intranet should be a “one stop shop” for all the basics that your staff need.

Now for the hard news: Intranets and software developers go hand-in-hand. You need a full-time web developer who can build the connections to the databases and provide the centralized access I described above.

What’s the point? Saving time. If you were to do an analysis on the amount of time your staff spends just searching for information, you might be surprised. Consider this: if you are able to save 10 minutes of time a day for 50 staff members by providing simple search tools on your intranet, that multiplies out to 8.33 hours per day. That’s a salary. That’s ROI.

Ok, let’s cut to the chase. Most books, in my opinion, are wrong on this subject. They usually tell you that if you want to start a business, you should consider things you are “good at” or things you enjoy doing and turning one of those affinities into a service to others for which you can get paid. I can’t disagree more - especially regarding service-oriented business start-ups.

My stance, particularly with providing a service, is to consider something you absolutely hate to do or are scared of. The chances are good that other people also despise or avoid doing that activity and will pay you to do it for them. Mowing yards, washing cars, cleaning bathrooms, and the like are all obvious examples of businesses you could start today because you probably don’t like doing these things - and neither do I. With some work, you can become an excellent provider of such a service and turn your avoidance of the activity into a passion.

For product-oriented businesses, think of something you want to purchase for yourself. The chances are good that others would also like to have “it”. Can you build/make the item from parts or obtain the item wholesale and re-sell it using eBay?

In summary, keep your hobbies. The things we like to do are enjoyable because we don’t have to do them - we want to do them. If you turn your hobby into a business, that’s not wrong - just don’t expect the time spent to be as rewarding as it used to be when you weren’t getting paid to do it - and be sure to find another hobby so you don’t go insane.

If you are going to write database software, you should use an application framework.  What’s an application framework?  Well, it’s a piece of software in and of itself.  So, in short, an application framework is software for creating software.  Frameworks take care of all the basics, so you, the software developer, don’t have to “re-invent the wheel” with these mundane tasks.  What are the basics?  Well, a good application framework should cover at least the following:

• Security - If you’re going to write nearly any database application, you’ll inevitably need to be able to control who can create, read, update, and delete information
• C.R.U.D. - Speaking of “create, read, update, and delete”, a good application framework will have these basic record functions readily available
• Navigation - I’m not talking about the look-and-feel, but the “nouns” that the user has permission to navigate to within the application
• API/SDK - Perhaps the most obvious aspect to a framework is its Application Programming Interface and its Software Development Kit

The basic application framework provides enough functionality to help you organize, secure, and access the data.  That’s the bottom line.  More advanced frameworks may also provide approval & workflow mechanisms, user interface options, and integrated reporting capabilities.

Large, old-school database applications which don’t utilize an application framework approach grow like a snowball: always adding more and more “stuff” to a central core.  When a new feature is needed, it gets tacked-on.  In contrast, application frameworks allow software developers to separate their development from the core framework, thus reducing the risk of negatively impacting tried-and-true functionality and providing a more scalable, agile, and stable solution.

Well, I’ve been looking for a new bass guitar ever since I went on the Guatemala trip.  I wanted something that looks good, but more importantly, the new instrument would have to have excellent tone.  A trip to Atlanta Bass Gallery finally ended my quest.  After being impressed with a Lakland Skyline and a Sadowsky Metro, the guys at the shop handed me a Dingwall to play around on.  What’s a Dingwall?  I didn’t know. 

After seeing the instrument, it came to me.  I had stumbled across this manufacturer in my online musings and had all but dismissed their products from my list due to the awkward-looking Novax Fanned Fret system they employ.  As soon as I began playing it, I realized I was holding a work of art, both aesthetically and technologically.  None of the other basses could produce as clear a tone as this bass.  Moreover, it is very easy to play.  I’m now the proud owner of a Dingwall Afterburner 5 string bass.

When planning a new software development, I often use a simple tool to help me analyze 3 things:

1.      Who is going to use the application/website?
2.      What do those people expect to get?
3.      What do those people expect to provide?

I call it the “Give-Get” matrix and I usually use MS-Excel to write it.  Here’s a sample for a fictitious Church member web portal:

This template helps to identify simple needs from each perspective.  From this matrix, you can identify overlapping functionality, assess the need for moderation/approval on each function, and evaluate how you are serving your audience(s).  You can also use this tool to evaluate existing software.

I was in Guatemala playing bass with a worship team from my church a couple of weeks ago.  I was talking with one of the Guatemalan bass players about several bass players and bass guitar manufacturers for which we shared a mutual respect.  We found common ground discussing some of the greats such as Jaco Pastorius, Victor Wooten, Abraham Laboriel and some of our favorite bass guitar brands such as Warwick, Ken Smith, Tobias, Pedulla, etc.    He asked me, “Do you know who Adam Nitti is?”.  I thought for a moment - “nope”.  Who is that?  When I got back to the states, I looked him up.  Dang.  This guy is blessed.  I’ve been listening to his albums over-and-over since they arrived at my house a couple of days ago.  Check him out on YouTube.

There are many systems required for managing the needs of an evangelical church.  I’ve listed the following 8 systems in an effort to get to a comprehensive “core” of what church management software should help manage.  There are many systems not listed here such as Workflow/Process Routing, Strategic Planning, and Web Content Management (although it’s touched on), as these merit their own discussion.  It’s not merely about having features, but having usable software that can handle real-world scenarios.  How does your church management software rank against this list?  What’s missing?

1. People & Families - It should go without saying that a church management database should manage people records.  On a scale of 1-10, how does your current solution handle the following?:
   • Quickly & easily add a new family or individual record
   • Add a new family member when a couple has a baby or adopts
   • Easily create a new family out of two individuals when they get married and remove them from their original families
   • Remove a family member when there is a divorce
   • Remove a family member when there is a death
   • Assimilation, journey, or growth management should help staff recognize where people are on their “spiritual walk”
2. Small Groups: Classes (Growth), Teams (Service), & Communities (Fellowship) - The church management solution should handle these 3 common types of groups in which people participate.  From 1-10, how does your current solution handle the following?:
   • Select several people and quickly add/remove them to/from a group
   • Manage people’s roles or leadership positions in groups
   • Manage people’s responsibilities in groups, allowing group members to go “on leave” and temporarily delegate their responsibilities
3. Departments & Ministries - These structures offer oversight, management, and accountability to the small groups.  These are separate entities from small groups and should be managed as such.  From 1-10, how does your current solution handle the following?:
   • Structure departments & ministries with unlimited hierarchy
   • Ability to separate a ministry into two new ministries
   • Ability to combine two or more ministries into one ministry
   • Ability to staff a ministry with volunteer & paid staff and manage staffing needs
4. Events & Activities - This is at least a church calendar; however, most churches also need an attendance tracking solution and a room reservation system.  From 1-10, how does your current system rate with the following?:
   • Event planning & budgeting 
   • Recurring meetings should be visible on the calendar as separate meetings, allowing for exceptions when conditions call for a cancellation
   • Event registrations should ideally be available online, but must at least be easily handled by church staff over the phone or via email
   • Attendance & participation management should show not only who attended, but how did they participate
   • Online or kiosk-based check-in
   • Room availability management
   • Resource availability management (projectors, tables, etc)
   • Servicing management (catering, childcare, etc)
5. Contributions - This area handles tithes & offerings as well as pledge campaigns.  From 1-10, how does your current solution handle the following?:
   • Contributors should be able to distribute their donation across multiple funds/appeals
   • Contributions statements should be made available monthly, quarterly, and, at least annually
   • The system should be able to quickly and intuitively process contributions
6. Finances & Accounting - The software must have sufficient accounting capabilities so the church can pay its bills and manage payments received for event registrations or products sold.  From 1-10, how does your current solution handle the following?:
   • Double-entry book keeping capability
   • Budgeting
   • Payroll
7. Communications - The software should at least be able to assist in bulk email and bulk postal mail.  However, these days, you should look for integration with your web site and publishing information via RSS feeds.  From 1-10, how does your current solution handle the following?:
   • Simple bulk email capabilities, with merge field capability
   • Create labels, print on envelopes
   • Create letters, preferably from templates, with merge field capability
   • Allow recipients to receive communications based on their delivery preference (email, web, rss, postal mail, phone call, personal visit, etc)
   • Manage web content with approval and document versioning
8. Reporting - The church must be able to perform complex queries against the database as well as obtain regular analysis on their efficiency as stewards of people’s time and God’s money.  Again, on a scale of 1-10, how does your current solution handle the following?:
   • A comprehensive report library which covers all aspects described above and provides parameterized input
   • The ability to execute and deliver (via email or other) reports on a scheduled basis
   • The ability to provide charts, graphs, and pivot tables
   • The ability to provide “drill through” capabilities, allowing users to investigate further
   • The ability to perform trend analysis by revealing changes in data over time
   • Should provide “Venn Diagram” ad-hoc querying capabilities such as “Give me all the people with criteria A, B, & C who do NOT have criteria D, E, or F”

Bottom line: The chords/riffs come first, the vocal melody comes next, and the lyrics come last.  This is a subtle difference from writing a pop song (where the vocal melody should come first).

Start with a riff.  What’s a riff?  A riff is usually performed on the electric guitar, acoustic guitar, or less commonly, the bass guitar.  The riff is a melody played out as moving chords or moving notes within chord positions.  So, just like writing a pop song, it all starts with a memorable melody.  Your riff may support just the verse while a more basic chord progression supports the chorus or vice-versa.

Secondly, consider the vocal melody apart from the lyrics.  Put a vocal melody on top of your riff and chord parts.  Don’t use words.  Just sing “na na” until you have a melody that you can use for the verses and one for the choruses.  Don’t mirror the riff!  The vocal melody should be different melodically and rhythmically from your guitar/riff parts.  They should compliment each other - not compete with each other.

Finally, after you have your riff/chord structure and a vocal melody to go with it, it’s time to write your lyrics.  The same rules apply here.  Use metaphor.  However, if you can sneak in a common saying or phrase (colloquialism), you will significantly improve the chances of your listeners connecting with your material.

There are 2 types of security systems/methods that you will find when developing or evaluating database software.  Good database software anticipates the need for both types.

1. Centralized Security - Also referred to as “Roles-based Security”, this common security structure allows “administrative users” to place other users into groups or “security roles”.  The permissions are granted to the role (not to the users directly).  Users are then assigned to the role and thereby obtain the necessary privileges to do their job.  This allows the administrator to assign a user to multiple roles based on their duties & responsibilities.  For example, your organization may have an accounting department which needs access to financial data that you don’t want other members of the organization viewing/editing.  In this case, an administrator may create an “Accounting Users” security role and assign that role to only the users who work in the accounting department.  I call this “centralized” security because the action of creating the roles and assigning users to those roles is typically done in a “central” location by an administrative user.

2. Distributed Security - Also referred to as “Record-level Security”, this not-so-common security structure allows users to secure individual data records.  As various users are viewing & editing data records (which they have rights to via centralized security), they may come across a particular record which needs to be made “private” due to its sensitive or confidential nature.  Users should be able to “lock down” these records as exceptions to the centralized security governance.  I call this “distributed” security because the action of securing the particular exception records is typically done by the end users as they work with the data and uncover or create information which deems the record sensitive or confidential.

As for the various levels of security, such as “read only”, “edit”, “full control”, etc, this depends on the software application; however, this should typically be pessimistic.  That is, users should not have ANY permissions to the data until it is provided through a security role.  Furthermore, “field-level security” indicates that a particular field (such as a social security number or other sensitive piece of data) be restricted from editing or viewing for a user or group of users.  Regarding field-level security, this should typically be optimistic and assume that users are able to manage all the individual fields in an area of the software unless restricted in some fashion.  From my experience, I have not seen a significant need to ever provide field-level security in a distributed context (a user can edit the social security number in record A, but not record B).  Usually, if you are wanting to hide a particular field from view/editing, this can be done in a centralized manner via a security role as it will most likely apply to all records.

As an additional illustration of “central” versus “distributed” security, consider the computer network you login to at your place of work.  The folders and files on the network that you have permissions to are most likely dictated by security roles to which your user account is assigned.  However, if you change the security settings on a particular file (such as a spreadsheet or document file) that you have rights to you have just demonstrated an example of “distributed” security by making that file an exception to the central security rules.

Over the years, I’ve established guidelines for building database software with a two-fold goal: 1. Make it easy to program for the development team and 2.  Make it easy for end-users to learn.  If you’re writing a new software tool, evaluating existing software solutions, or trying to learn a new database software product, breaking the software into the following layers will help you work towards understanding the fundamentals of the product and aid in your success in writing, learning, or teaching the solution.

Navigation - This is usually accomplished using “tabs”, a “tree view”, or something similar and should be labeled according to the primary “nouns” the database solution manages.  For example, consider the tree view control inside MS-Outlook.  It contains an “Inbox” for email messages, a “Calendar” for appointments, and a list of “Tasks”.  All nouns.  If you see words other than nouns in the navigation area of the software, especially verbs such as “Create new message” or “Create new task” as a tab or a tree view node, expect decreased usability and increased training time.

The Three S’s: Search, Sort, and Select - Once you’ve navigated to the nouns you are interested in working with, you should be able to search the list, sort the results, and select the particular records of concern or interest.  If the solution does not provide a simple means to accomplish these three functions in a simple, intuitive manner, expect confused users and a feeling of being isolated from the data.  When end users navigate to the “nouns” they are interested in working with, they don’t want to see the software standing between them and their data - they want to see their data.  Moreover, they want to be able to perform the three S’s.

C.R.U.D. Management - C.R.U.D. stands for create, read, update, and delete.  These are the basic operations that the database software needs to perform for managing data.  The more consistently the software can handle these basic operations, the easier it is for the software developer to scale the software and the easier it is for the end-user to learn these basic functions.  If navigation is about the “nouns”, CRUD is certainly about the “verbs”.  Verbs should be identified in the user interface as buttons or toolbar items.  “Create a new record”, “Save the record”, and “Delete the record” should be buttons or in a toolbar.  End users are accustomed to seeing these standard operations this way - don’t confuse them. 

Tools & Wizards - Advanced data operations (beyond simple CRUD management) should be performed using action dialogs & wizards which will guide the end user through a specific task.  Like any verbs, tools & wizards should be launched from buttons or a toolbar so as to associate their use with adding/modifying data.  The “features” list of the software should be evident in the tools & wizards made available to the end user.  If the user is excited about a particular feature in the software and that feature is explicitly identifiable by means of a tool or wizard dialog, the probability of success for both the developer and the end user increases dramatically.

Reports - If C.R.U.D. and Tools help the user get data into the system, certainly reports help get the data out.  But, more than that, reports should turn the data into information.  Each report should have a clear description that states succinctly what kind of information it returns and how it is intended to be used.  Furthermore, 90% or more of the reports should be “parameterized”.  This means the end user has the ability to specify a date range or other information which may filter the results according to their needs.

In summary, these are simply the fundamentals that I use when evaluating and writing database software.  Advanced solutions would require a fourth “s” to be added: security; however, this topic goes beyond the scope of this post.

I’ve played on Church worship teams for nearly 20 years now in some form or fashion.  One of the issues that seems to keep coming to the surface - especially in the larger venues - is that of self-indulgence.  When does a player “cross the line” and go from worshipping God to worshipping himself or herself?

First of all, don’t believe the anti-performance nonsense that many in the church and in Christian music in general are preaching.  To have a venue with a large auditorium, stage, lights, PA system, and then tell musicians that they are not there to perform is ridiculous.  There’s a medical term that describes this type of mindset: schizophrenia.

Sure, you are not there to garner all the attention towards yourself - duh.  But this is true of any musician in any professional group or band.  Musician’s have to know their roles and work as a team whether they’re singing about God or secular themes.  Instead of preaching “don’t perform”, we should be preaching “be professional”.

Bottom line: The melody comes first, the chords come next, and the lyrics come last.  If you can hum or “na-na” a melody line and then put chords under it, you’ll have a better chance of producing a memorable song, period.

Start with the melody.  These come to me all the time.  When I’m driving with the radio off or I’m in an airplane or whatever.  It’ll usually be a melody that I’ll use for the chorus of a song.  I will “na na” the melody until it’s stuck in my head, then I’ll try to come up with a complimentary melody to use for the verses of the song.

Keep your chords basic.  Use primarily I, IV, V, and vi chords for a pop genre.  Try to match the key signature that you are humming.  Use the same progression for all the verses and a variation of the progression for your choruses.  Shoot for a 4 minute length.  When you’ve gotten accustomed to writing songs this way, you may want to add a “pre-chorus” melody & chords or a bridge.  However, avoid making your song any more complicated than it really needs to be.

Once you have your melody and chords worked out, you have essentially a “blank slate” for fitting the lyrics into.  Use metaphor.  Don’t be overly literal when you are writing lyrics.  The problem with literal lyrics is they don’t leave room for the listener to identify with your song in their own personal way.  Your song should be a piece of art - not a soap box.  Good art is good because people can identify with it.

Christian music doesn’t exist.  Please stop using that term.  Christ’s sacrifice on the cross was for the redemption of people, not music.  Christian music is not a genre - it’s a theme.  People should be able to sing songs with a God-oriented theme in many genre’s - according to their tastes.  Perhaps the question we’re really trying to answer is what musical genres work best in the institutional church?

Christian worship music (at least in the predominantly white churches I’ve attended) is typically a mix of folk, country, adult contemporary/easy-listening, and pop genres.  There was more R&B influence in the 90’s (let’s pray it comes back!) with some of the recorded worship leaders such as Ron Kennoly.  It’s more than semantic nit-picking.  To label Christian music as a genre fosters a limiting mindset on what is “appropriate” and what is not.

As a worship team member, understanding the genre of the music you are playing is critical.  For the same reason you wouldn’t bring an acoustic guitar to a thrash band rehearsal (unless you were planning on smashing it), don’t bring a skull & crossbones electric guitar to praise team rehearsal.  Why?  Simple: it doesn’t fit the folk, adult contemporary, and pop genres.

Participating in a worship team on stage during a church service is itself an act of worship - but not how you may think, and certainly not in the same way as that of the congregation.  Playing on a worship team is work.  Your service and effort put towards a professional quality is your worship.  Your role is different than that of a congregation member, and so is your worship. 

It is a wrong assumption to think that worship leaders/teams are worshipping in the same way as members of the congregation.  Congregation members, like most audiences, will feel the way you as a performer look like you feel.  If the praise team all have solumn expressions on their faces, it will affect the mood of the congregation - regardless of the feel of the music.  If you miss a note or start a vocal line early and this causes you to lose your composure (instead of calmly ignoring the issue), the congregation will feel the awkwardness you feel because that is what you are showing them.

Worship teams are worshipping well when they are demonstrating worship.  This demonstration of worship comes from a commitment to excellence and professionalism on stage and in rehearsal.  This commitment to excellence comes from the musician’s acknowledgement of their talents as gifts from God and the music as worth playing because God is worth it.

A worship team is just that - a team.  Like any other team it relies on clearly defined roles to be established and adhered to.  In addition to roles, worship teams must work to establish parts for each song.  For a team member to say, “my part is to play the bass guitar” or “my part is to sing” demonstrates a misunderstanding of the crucial differences between a role on the team and the part in a song.

Did you know that a drummer can play a vocal part on the drums?  When this happens (and it does happen), the music sounds cluttered.  If you want to take your worship team to a professional-level, you must go beyond a simple recognition of each member’s role on the team and work to identify and understand each member’s part in each song.

The best thing about musicians knowing their own part is they know what not to play - i.e. someone else’s part!  Being aware of not only your own part in a song, but also the parts of others is one of the main goals of rehearsal.  Instead of trying to get all the musicians to learn the song, help them to learn their part in the song.  This is a very common approach between vocalists.  Get the musicians to do the same thing and you’ll be impressed with the results.

When a worship team doesn’t sound “tight”, 9 times out of 10 it’s not for lack of ability - it’s due to a lack of discipline.  If the drummer simply plays a consistent, basic beat - just like a drum machine - and the bassist simply plays exactly with the drummer’s kick drum pattern, you will have a tight-sounding song.  No fills, crashes, or runs - just solid.  That’s the fundamental and that’s where every rhythm section should start for every song.

The problem is drummers don’t want to sound like a drum “machine” and bassists don’t want to play simple notes on every kick drum hit - it’s boring.  Right.  Keyboardists, pianists, and guitarists likewise need to keep things simple - especially while the vocals are singing a phrase.  If the challenge for the drummer and bassist is to work to sound like a machine, surely the challenge for the rest of the members of the team is to make “room” for eachother.

As I’ve mentioned before, the lead vocals and the kick drum are the most important elements of a pop song.  Regardless of the challenge to keep your parts simple, the drummer and bassist must respect the priority of the kick drum and the rest of the members must respect the priority of the lead vocal.

Knowing the equipment on stage is crucial for your success on a worship team.  If you think you’re just there to sing and you don’t need to know something about microphones, you’re wrong.  Knowing the difference between an omni-directional mic and a mic with a hyper-cardiod pattern is as important for a singer as knowing the difference between an electric guitar and an acoustic guitar is for a guitarist.

If you know what kind of microphone you are singing into, it will help you utilize it properly.  How close should I hold this mic to my lips?  Why is there feedback with my microphone, but not with someone elses?  Knowing just the basics about microphones will help you answer these types of questions and improve your overall capabilities as a vocalist.

Your monitor mix is not there for you to listen to the song.  It is there to help you perform your part in the song.  You shouldn’t set your monitor mix so that the music sounds good - you should mix the song so as to help you do your job.  This may mean cutting out some of the parts all together or having one or two parts noticably louder than the rest of the mix.  You are the first priority in your monitor mix.  You must be able to hear yourself.  But, beware - this fact doesn’t necesarily mean that you should turn yourself up!  Turn the rest of the parts down.  Your ears will thank you later in life.

I'm slowly getting my website back online.  Please be patient as I upload content and files.  God bless,

Stephen