Project Management, Communication and Collaboration Specialist
Nik is a project manager and web technologist that enjoys solving peoples' problems through web technologies. When he isn't doing those things, he's lifting heavy things up and down repeatedly, and cooking with his 3 children, who are actively trying to eat all the ingredients.
Although a lot of people prefer to use the mouse to click around, most IT professionals prefer the keyboard (and associated keyboard shortcuts), because it can be a real time and effort saver. When you spend more than 8 hours a day at a computer 5+ days a week, saving a few seconds here and there really adds up. To that end, here are some of my favourite Windows keyboard shortcuts:
Win + D: Show The Desktop. Minimizes all currently open windows to show the desktop. To restore all your windows, just hit Win + D again.
Win + E: Open Windows Explorer.
Alt + Tab: Cycle through open windows. (Use Win + Tab for the fancy Aero version of this)
Win + L: Lock your computer. When you return you have to enter your password. This is not only security best practice if you’re stepping away from your computer, it also prevents your co-worker from changing your desktop wallpaper to Rick Astley.
Win + Left Arrow: Align Window Left. Great for when you have a widescreen monitor and need two windows side by side (use in conjunction with Align Windows Right below).
Win + Right Arrow: Align Window Right
Win + Shift + Left/Right Arrow: Move a window to another monitor.
Win + R: Open the run command. Great for opening up Windows stalwarts like calculator (calc).
Win + F: Open search.
Ctrl + Shift + Esc: Open Task Manager. Great for when your system is having a panic attack.
Recently I ‘inherited’ an InfoPath form to clean up and expand the capabilities of. The project is fun and interesting, so I thought it would be a quick and easy exercise. Unfortunately, when I opened the form, to my horror, none of the fields were named or organized in any way. This isn’t a big deal on a form with a dozen fields or less, but this bad boy had 236 fields, named field1, field2, field3 … all the way to field 236. Worst still, the fields weren’t in any order in the fields window; checkboxes at the start of the form were at the bottom, and text boxes at the bottom were somewhere in the middle. It was literally impossible to tell what field was what.
This happens easily and regularly, because when you pop a field into InfoPath, it’s automatically assigned a name of ‘field#” (where # is the number of that field). When you’re quickly throwing together a form, it’s easy after a few dozen clicks to have an unmanageable, unorganized number of fields.
Referring to these fields in InfoPath by ‘field#’ is not best practice, and frankly it makes your fellow InfoPath developers weep before bed every night – oh, and wastes tons of time trying to figure out what field is what. For example, good luck building rule sets with conditions like:
field23 is equal to field94 AND field 12 is not empty AND field104 is greater than field 197.
This. Makes. No. Sense.
There is a better way: The 6 rules below will get you well on your way to organizing and bringing sanity to an insane InfoPath world.
How To Organize InfoPath Fields
Keep your sections and fields in the order they’re displayed on the form. Moving fields around can be a pain, but it makes the field list more logical and easy to navigate. Tip: It’s a lot easier to move fields around when they’re inside of logical sections (see ‘Use Sections’ below).
Use CamelCase to name sections and fields to make the names more legible. Since InfoPath does not allow spaces in field and section names, using CamelCase can make it much easier to distinguish distinct words for field names. For example: producttype becomes ProductType.
3. Use Sections
Sections aren’t just for conditional displays. You can create them in the Fields window to separate logical groups of controls, or even blocks of text. If your form has logical sections or separation of content, use groups to define those sections in the field list.
4. Descriptive Names
In programming, Hungarian Notation is a naming convention used to describe variables and functions. I use a similar system in InfoPath to help describe the type of field I’m using, so I can quickly know what kind of control it is, and by extension the type of information being captured. For example, if I’m using a text box, I prefix the name with ‘txt’. So FirstName becomes txtFirstName.
Field Name Prefixes
Drop Down List
Date and Time Picker
Person/ Group Picker
External Item Picker
Object Name Prefixes
I tend not to append the section type with a prefix, because it’s more important to give it a descriptive name, and then name any fields inside with a prefixed, descriptive name. After all a section is a group of data, not the data itself.
5. Give Rules Action Names
I know, Rules are technically not InfoPath fields, but all the same you should always give them a good, descriptive name. Much like fields, by default InfoPath gives the rule a name like ‘Rule#’. I use a descriptive name that includes a verb, which describes the action the rule is actually doing.
A common rule is to make a section hidden if another field does not equal a particular value, in this example, I name that rule ‘MakeHidden’. Similarly, if a field has a rule that makes that field required based on another field’s value, I’ll name that rule ‘MakeRequired’.
Rules are only as good as how consistently they’re applied. I know it’s more work to name, order, and section everything properly, but trust me, it will save you (and others) time and effort in the future. Apply the above rules across an entire form every time you create a form – and when you can glean what the form is and what it does in 5 seconds flat, pat yourself on the back.
InfoPath makes it so easy to bang out a form in just a few clicks, but the cost of this is lack of enforcing any kind of structure or rules to that will help you and others in the future to remember how the form is structured and what it’s actually doing.
Ordering your fields, using CamelCase, Sections, Descriptive Names, Rule Names, and Consistency are 6 quick and easy ways to bring some sanity back to your forms, and save you and your coworkers a significant amount of blood, sweat, and tears.
Inside just about every organization that uses SharePoint, there’s a quietly seething war happening. No, it’s not between you and the person that keeps stealing your food from the fridge – but honestly, who does that?
It’s between the SharePoint IT crowd and the business end users.
Both sides think the other abuses SharePoint and makes it unusable, and both sides think that the other should just shove off and let the people who know what they’re doing handle the situation. This kind of conflict happens most often when strong governance isn’t in place before, during, and after SharePoint is deployed – since governance is almost always either totally undeveloped or underdeveloped, the battle between IT and users is a common one.
So What’s The Problem?
There are two fundamental approaches to SharePoint:
Scenario 1: SharePoint Owned by IT
IT is told to deploy SharePoint to allow people to collaborate, communicate, and various other ate’s. Usually this means a server admin installs SharePoint, gives the business user(s) limited access (usually Contribute), and considers the service request fulfilled. Business users are given the URL, told how to login and left to their own devices. IT favours this approach, as they tend to dislike relinquishing control of their infrastructure and resources to non-IT personnel. Business users tend to hate this approach, as they must now must submit tickets to IT for just about everything you can do in SharePoint: manage permissions, create lists and libraries, etc.
The conflict between IT and business here comes from business feeling like they’re constantly on a leash that IT holds. Business wants to do things right now and doesn’t have time to wait on IT to get what they need done, and they don’t want to be subjected to IT decisions such as server moves, downtimes, etc.
Scenario 2: SharePoint Owned by Business users
Usually this scenario happens when a business user catches wind of SharePoint at a conference, trade show, or meeting with a colleague, and and it’s love at first site (pun intended). Someone within business with some tech savvy and initiative fires up a server, installs SharePoint, and lets the business user community go at it. Business users really love this approach, as they now have a powerful technology stack under their complete control, which they can (in theory at least) make jump through the hoops they need jumping through. IT, on the other hand, is fuming mad, because they definitely do not like being kept in the dark when it comes to someone deploying servers in their environment, especially when something blows up a year later and are told that they have to fix it.
In this scenario, the friction comes from IT feeling left out of the decision making process and told they need to clean up when something business has chosen to do has blown up. Most often IT will propose bringing the server ‘into the fold’ to which business users will dismiss outright and fight tooth and nail to keep their toys in their backyard. IT becomes frustrated because they become a cleanup crew, but business enjoys it because they get all the benefit, and risk is absorbed by IT.
Power Up To 11
At it’s core, this whole situation is a power struggle. In Scenario 1, IT feels empowered but business feels powerless. In scenario 2, it’s just the opposite. Neither approach truly works, because it creates a lopsided power dynamic that always leaves one side mad, frustrated, and wanting to hit the “ABORT” button on the whole thing.
The only solution is to establish a hybrid model – a power sharing approach that involves both groups to empower each other.
The Fix: IT Enables, Business Executes
The most first step is to have IT and business stakeholders sit at the same table, ideally as a part of a larger governance committee. The various stakeholders from both sides need to flesh out the divisions of responsibility and the expectations they have for each other.
In essence, both sides need to communicate with each other and on a regular and permanent basis. It doesn’t work to have one meeting before kickoff, and it doesn’t work to do it sporadically when people feel like it (and for God’s sake don’t do it on a Friday afternoon). Depending on your level of use of SharePoint, this could mean a bi-weekly or monthly meeting between IT and business to keep each other informed and head off issues and conflict before it even happens.
A great tool baked right into SharePoint to facilitate this kind of integration between IT and busines are Blogs. I’ve found creating a blog where technical and non-technical stakeholders can post updates, discuss issues and keep each other informed is invaluable.
Render Unto Caesar
After the initial discussions above, you should start to have a pretty clear understanding of where each of the responsibilities lay.
Let’s be honest here: business users do NOT want to have to deal with server health, backups, patches, combing through the ULS logs troubleshooting, etc. Nor should they! This is IT’s bread and butter. Business users should be focusing on business: how to improve, how to be more efficient, how to use the tools.
Similarly, IT should not have to be contacted every time permissions have to change or a list needs to be created – this is the day to day business side, and frankly IT has better things to do with their time. Therefore, business users must be trained and trusted to take on all of the day to day responsibilities. Training is critical for both sides, because the more training they each have, the more they can focus on getting work done and the less they have to ask the other side to solve their problems with SharePoint.
In my mind, the business owner of SharePoint should be able to perform all of the operations available to them up to the Site Collection Administrator level; everything from managing permissions to workflows and sandboxed solutions. IT, on the other hand, should have the knowledge and ability to proactively address issues before they become problems, and work with business to quickly address problems.
What we’re talking about above, really, is governance. Stakeholders coming together to define and work together to determine the who, what, when, where and why of SharePoint as a tool. Write down the outcomes from these discussions. Share what you’ve written down with the group. This is how you can start to develop a framework for governance that can be built on over time. Governance doesn’t have to be a giant, monolithic project (but you do have to address it at some point), you can start small and iterate to a larger goal.
SharePoint is a unique bird in that it will starve if one group keeps a strangle-hold, but it tends to thrive when multiple groups buy into the technology and work together to develop it into a success. IT and business aren’t mutually exclusive, they’re part of the same workplace ecosystem, and as such, what’s good for one side is good for the other. IT and business can work together, and indeed they must work together if SharePoint is to be a cause for celebration rather than a source of conflict.