Skip to content

Articles

Developing photos

Article: A Developer’s Path to Freedom Through Apps

Rarely is there a developer I come across in my travels who isn’t interested in starting their own company and creating the next big app. Actually, it’s more accurate to say that most developers have a view of creating an app as a way to win the lottery. It’s the shared dream of retiring early, driving sports cars, and leaving the cubicle police far behind.

The good news is that the dream has become a reality for some. They’re already where we want to go—so they can help us get there too. The bad news is that the road isn’t straight and it’s not without work. Sometimes, more work than people expected. Along the way, I’ve met folks who’ve tried and failed, who’ve soared and crashed, but there is wisdom in their stories, too. In this series of articles, we’re going to look at building apps and how they can lead you to freedom or just another prison. The first stop is the road through independence.

The vision we have is that those who’ve created their apps and are living the good live starts in one of two ways. They start as a lone wolf coding through the night living on Mountain Dew and Cheetos, or they start as part of a posh startup located in a city we don’t live in who received their funding from an angel investor—who you have no hope of meeting.

Read more…

die face

Article: Six Things Every Developer Should Know to Stay Current

Our technology world is spinning faster, and sometimes trying to figure out what you need to do to stay relevant to employers and to continue to enjoy being a developer is difficult. It seems like every day there’s a new release of a language, library, or technology that you need to know to be at the top of your game. With that in mind, here are six things that you can do to stay current.

1. Protect Your Passion

You became a developer for a reason. You’re good because you love it—or at least you did at one time. If you want to be a great developer, you have to maintain or regain your passion for the craft. This can mean developing a game in Unity “just because.” It can mean developing an Internet controlled toaster with a Raspberry Pi II.

The point isn’t what you do to have fun with your development again—the point is to have fun. The best developers are those who’ve got a passion for their craft. If you’ve got it, keep it. If you’ve lost it, find it.

Read More…

Article: Validating Software Requirements

Unit testing and test driven design don’t help you if your requirements aren’t right. It may be that trying to create the tests will expose that you have a problem but wouldn’t it be nice to know that there are gaps in requirements before you sit down to write code? Although it’s impossible to get perfect requirements, most developers would love to get requirements that are better than what they’re getting.

Whether you’re getting requirements from a business analyst or you’re creating them yourself, here are a few simple tips for ensuring that your software requirements are right. These tips are pulled from my Pluralsight course Gathering Good Requirements for Developers.

Ensurance

Here are some things that you should check to ensure they have been covered:

  • Are all the stakeholders represented? Have you received feedback from all of the parties impacted by the solution?
  • Do you have functional requirements for all user requirements? Were you able to translate all of the high-level user requirements into specific requirements?
  • Do all of the events that the system must respond to have responses? If you look at all of the events such as approvals, rejections, creations, and the like, do they all have a system response?

Read more at http://www.developer.com/design/validating-software-requirements.html

Article: Yammering About Development

Years ago, we heard about a movement in software development that was more about individuals and interactions than processes and tools. It was about responding to change and not a rigid plan. Of course, I’m quoting from the Agile Manifesto.

Agile development didn’t spring to life overnight, but slowly and over time we’ve adapted as an industry a more agile approach to how we develop software. A similar change is happening in the way that we communicate, and it’s happening in the same fits and starts that agile development initially had. The change is about collaboration, not negotiation. It’s about getting things done rather than having documentation. The changes that we’re seeing in communication follow the same openness and transparency that created agile nearly 15 years ago.

One of the tools that stands to change the way that we communicate is Yammer. Microsoft purchased Yammer in 2012 and has been integrating it into its products and services, creating a future that includes Yammer integrated into the Office applications we use every day.

But the question is how does a mass-market enterprise social tools help developers write better software? Clues are in how Yammer aligns to the direction we’ve been headed for years and what we’re already doing in person for agile development. Clues can also be found in the way that we collaborate outside our enterprise, despite Yammer being described as the enterprise social network.

Read more at: http://sdtimes.com/yammering-development/

Article: Eliciting Vision through Exercises and Games

The process of developing detailed requirements – or even a well-articulated vision – can be an excruciating process without the right facilitation techniques.  In a broken process the person gathering requirements doesn’t know what to ask and those who want the solution have a hard time articulating what they want and need because they don’t know how to share their thoughts with someone from the outside.

Facilitating a discussion takes skill and curiosity, however, in many cases that’s not enough to convey the richness of the desires of those who want the solution.  What’s needed is a framework for success.  Forming a framework based on the learnings of knowledge management for the last 20 years and instructional design of the last 50 or so years creates opportunities to gather requirements and vision more quickly and with greater vibrancy.

Fish and Water

If fish could talk and you asked them what water was like, how might they answer?  They’d probably answer the same way we’d answer about air.  “It’s the stuff you’re in.” Or perhaps, “It’s always there.”  Because fish have never known anything different, it would be hard for them to articulate an alternative reality.  Likewise, if a fish were trying to describe the properties of a house, it’s unlikely that they’d mention that it has to be something that will stay together in water – because from the point of view of the fish that is obvious.

This is the fundamental challenge of eliciting vision and requirements.  When you’re “in it” you can’t see it.  It’s up to the person gathering requirements to create an opportunity for the person with the knowledge and vision to get outside of their environment and their standard ways of thinking long enough to be able to communicate the obvious.

Read more…

Article: Eliminate Costly User Experience Mistakes

Far too many web site design projects are plagued by continuous changes to mockups, or changes to the user experience after it’s already been implemented. While seemingly inevitable, these changes are both costly and unnecessary.  Leveraging a staged approach to development of the user experience can reduce costs, frustrations, and time.

The process revolves around the idea that you move from the least specific to the most specific user interface while covering both the static – what people see – and the dynamic – how they interact.  The process outlined below is designed to continuously elicit requirements and improve understanding earlier in the process – with less investment.

Projects that attempt to skip the steps outlined here often go directly to the mockup step and end up in countless iterations because there’s a lack of clarity about what the end goals are.  This lack of clarity makes the mockup the virtual dog chew toy, as one group struggles to move the mockup closer to their vision.  Ultimately, another group sees the move as moving away from their vision and they attempt to pull it back.  By progressing through a rational design approach, the unnecessary work of continuing to develop iteration after iteration can be eliminated.

Read More…

Article: Setting Goals with Conflicting Stakeholders

Getting everyone to agree on goals is a challenging undertaking in any organization.  Different stakeholders necessarily have different concerns and perspectives.  Those differences lead to a desire to have different goals for a project, an initiative, or an organization.  Getting everyone to understand those diverse perspectives and interlocking constraints is never easy; however, there is a technique which makes the process easier.  The technique of Dialogue Mapping creates an opportunity to reach a shared understanding of a wicked problem.  Many organizations face wicked problems – even if they aren’t aware of the problem’s wickedness.

Achieving shared understanding through the process of Dialogue Mapping leads to the opportunity to develop an approach to change the problem.  This is the heart of setting goals as a team – developing a shared understanding of the problem and developing a set of goals from that shared understanding.

Wicked Problems

Horst Rittel first used the term wicked problems to discuss problems that have a set of interlocking constraints and have no stopping rule.  There’s only better and worse – there is no right and wrong.  His experience was urban planning, where you can’t test the impact of a change without doing the change.  You can’t really see how a new road will impact a community until you build it and once you’ve built it you can’t un-build a road easily.

Wicked problems are really very large systems or, more accurately, sets of interconnected systems that operate together.  Because of the complexity, there’s no straightforward way to view the problem or to design a solution without the risk of introducing unintended side effects.

Read more…

Article: SharePoint of the Future – Tales from the SharePoint Conference

Whether you’re in Venice or Las Vegas – or both – 10,000+ people is a lot. The number is staggering, particularly when you walk into the keynote hall and can’t see anything but a sea of chairs from wall to wall and wall to wall. The keynote stage seemed like it was in a different zip code than the back of the room. That might have been a good thing for one of the ad-hoc communities that sprung up around the conference who were trying to get their steps in to report their progress via FitBit.

The SharePoint community seems like one large community but at 10,000 people it’s more like a collection of communities than a single group. With folks running, walking, doing fitness, and doing drinks, there weren’t many places in the Venetian that you couldn’t find a few people connected to SharePoint – and talking about the new things that Microsoft announced at the conference.

http://www.sharepointbriefing.com/spother/sharepoint-of-the-future-tales-from-the-sharepoint-conference.html [Website removed]

Retro: Harness Properties in SharePoint Search

Originally published on 8/21/2005

Most users of SharePoint Portal Server rapidly become enamored with the ability to add new fields (containing meta data) to documents in the document library. All of the sudden it becomes possible to associate information to a file beyond the file name that we’ve been limited to since the beginning of the computing era. However, few users have the opportunity to understand how this meta data is used by SharePoint for searching. This leads to problems when users decide that it’s necessary to use SharePoint Portal Server Search to search on information contained in a field that they have added. In this article you’ll learn how SharePoint uses document library fields to create properties which are searchable and how to enable searching on those properties.

The Power of Properties

SharePoint Portal Server’s search facility really works in two different ways. First, there’s the full text search. This searches across all of the text in every document that is in the index. This search is what most people think of when they think of SharePoint’s search capability.

Second, there is the property search. During the indexing process, the IFILTERs which extract the text out of the documents put property information into special property buckets which are kept separate in the index so they can be searched separately. This allows you to set properties in your Office documents such as department, project number, author, keywords, etc., and then you’ll have the ability to search on those fields individually. You can use the search engine in SharePoint to search for documents where the department is engineering and the project is 123. Where a full text document search for engineering and 123 may find hundreds of entries because the words engineering and the number sequence 123 appears in many documents, a search via properties may yield the 10 or so documents that are truly relevant to your search.

Properties are what most people believe that they are creating when they create a new field in a document library. That’s not actually true. The meta data fields in a document library don’t have anything to do with properties directly.

Office Does a Slight of Hand

However, during the edit process Office perform a little slight of hand. It takes the information you enter in the meta data fields for the document library and makes corresponding custom properties in the document. The net effect is that although you’ve only created fields in a document library, you’re documents now have custom properties.

These custom properties are picked up by the indexing process (more specifically the IFILTER for Office documents) and they are placed into the search index. You can then use those properties by making them available via the advanced search page in SharePoint.

However, this also means that non-Office documents don’t share the same relationship between fields in the document library and the properties of the document itself. So if you’re trying to develop a searching mechanism for documents like TIF documents or PDFs you’ll find that setting up a meta data field for those document libraries won’t allow you to search for those documents directly via their properties. You’ll still be able to organize the information

Setting up a test

Now that we understand the basic mechanisms of how SharePoint uses meta data and properties let’s demonstrate how it works. Here’s what you need to do to set up the demonstration.

  1. Create a site. For instance, I used /Sites/Test.
  2. Open the Shared Documents library by clicking on the Quick Nav Bar link to Shared Documents.
  3. Click on the Modify Settings and Columns link in the left bar.
  4. Click on the Add a new column link
  5. Enter a name in the Column name box. You can select any name you would like, I used Rob, Try, and IntranetJournal as my field names.
  6. Click the OK button.
  7. Repeat steps 4-7 for any additional columns you want to create. I repeated the process two additional times to get my two additional fields in.
  8. Click the Go Back to “Shared Documents” link to return to the Shared Documents Library.

Putting it to work

Now that you have a document library with custom fields, you can create a few new documents. Here’s what to do:

  1. Click the New Document button on the task bar.
  2. Enter some basic text in the document. (This text can be anything you would like.)
  3. Click File-Save.
  4. Give the document a name and click the Save button.
  5. Enter the meta data into the fields which are displayed. You should consider entering different text than the text you used in the document.
  6. Click the OK button.
  7. Close Word.
  8. Verify that the text that you entered is visible in the new fields on the document library.
  9. Click the document you just created in the document library list and click OK to the warning dialog if necessary.
  10. Click File-Properties. Notice that the meta data properties from the document library appears.
  11. Click the File Properties button. The standard Word document properties dialog is displayed.
  12. Click the Custom tab.
  13. Note that the meta data that you entered for the document library also exists as a custom property of the document.
  14. Click OK to close the properties dialog.
  15. Close Word.

Now you have a document in SharePoint with properties so you can go setup the search for them.

Ensure that the Document is Indexed

Before you can search on your new property you have to first ensure that SharePoint has indexed the document. This is done from the Portal by following this procedure:

  1. Open the SharePoint Portal
  2. Click on Site Settings in the navigation bar on the top of the window.
  3. In the Search Settings and Indexed Content section, click the Configure search and indexing link.
  4. In the Content Indexes section, click on the Manage content indexes link.
  5. Hover over the Non_Portal_Content link, drop down the menu via the arrow on the right, and click Start Full Update.
  6. Wait for the Last Update Status for the Non_Portal_Content index to display the word Idle. The page will automatically refresh itself.

Set up the Properties for Search

We had to ensure that the document was indexed so that the new properties would appear. During the indexing process the IFILTER which processes Word files automatically created new entries in the SharePoint Search Property list for the properties which were discovered in the document we just uploaded. The final set of steps are to enable the properties on the advanced properties page. To do this follow these steps:

  1. Open the SharePoint Portal.
  2. Click on Site Settings in the navigation bar on the top of the window.
  3. In the Search Settings and Indexed Content section, click the Manage properties from crawled documents.
  4. Click the plus sign to the left of urn:schemas-microsoft-com:office:office.
  5. Scroll down to one of the names of the fields you added to the list above (and verified became a property). Click the property from the list.
  6. Check the Include this property in Advanced Search options checkbox.
  7. Click the OK button.
  8. Click the Return to Portal link at the top of the page.
  9. From the Start Menu select Run and then type in IISRESET and press return.
  10. Click the magnifying glass to the left of the drop down list containing the text All Sources.
  11. Expand the drop down underneath the Search by properties: label to see that your new property is available to be searched.

You can now search SharePoint Portal Server for just the field you added in the list . Of course, as you have seen, you’re actually searching the property that was added to the Word document, but the effect is the same since Office is managing the transition to the document properties.

Retro: Drawing a Target on Your Users with SharePoint

[I’m reposting a handful of articles which are no longer available on the Internet as blog posts so that they’re not lost forever.]

Originally published on 6/10/2008

One of the challenges with most portals, including Intranets is maintaining relevancy of the information that the user sees and interacts with. You’ll hear a ton about search relevancy but relatively little is said about what is displayed on the home page. Some organizations approach the home pages as simple landing pages, a place for links to other places. Others try to serve up relevant content but all too often there are substantial portions of a corporate intranet home page that just aren’t relevant. If you’re in Indianapolis, how important is the company picnic taking place in New York?

In our information overload culture we’ve gotten adept at blocking out advertising and other non-content items on a page and still ad blocking software is in widespread use. We can filter information ourselves but the more we can filter information for users the better they like it. The more focused we can make our content the better the user experience. Luckily SharePoint has several ways that we can deliver customized content to users and groups.

One Size Fits All

Perhaps in some things one size does fit all. Golf balls are regulation size so in that sense one size does fit all. However, in most things we want to be unique, expressive, and interesting. If you don’t believe me walk into mall and notice the wide array of mobile phone covers that are available. There’s enough face plates that you can have any color that you want. That’s not all. Your mobile phone should be unique like you so there’s holographic screen protectors, and other kinds of “bling bling” to make it unique.

While I can’t advocate putting “bling bling” on the home page of your portal, one cannot ignore that individuals are just that – individual. They need different information at different times and for different reasons. Part of developing a portal is focusing on development of a solution that adapts to the major groups of users and tries to meet their specific needs.

In SharePoint there are three basic ways of accomplishing this as discussed in the following sections.

In-Part Personalization

Perhaps the easiest way to manage personalization is to have the web parts that you include on your page manage the personalization themselves. Whether it’s a web part for the weather that asks for your ZIP code and remembers it from visit-to-visit or a web part that remembers your search preferences, web parts in SharePoint can have personalized information that allows users to personalize their unique preferences – if the web parts support it.

Although the easiest to manage In-part Personalization does have the disadvantage that the web part itself must be coded to support the personalization – it’s not something that you can add in later. The out of box personalization support in SharePoint means that support for personalization in the web parts that you develop is transparent. Literally, there’s only one attribute that changes to make a property of a web part work for user level personalization.

In part personalization is great for web parts that you create – however, it simply doesn’t work for some third party solutions and some of the out of box web parts. It also can negatively impact performance if there are a large number of users customizing a larger number of web parts on a page. As a final note, this is truly personal personalization, meaning that it must be done on a user-by-user basis and it must be done by the user. That means most users won’t take advantage of the functionality unless the web part makes this process very easy.

Peacock of Parts

A somewhat more challenging approach, but one that offers the ability to layer on personalization no matter who wrote the web part or when they wrote it, is the targeting engine in SharePoint. Targeting in SharePoint is best known through the MOSS audiences implementation. Audiences are compiled groups of users to which web parts and information can be targeted to. The implementation of audiences is on top of a public interface called IRuntimeFilter2. Without going into too much detail, it allows you to add additional editing controls in the editor zone and supports the events necessary to make sure that these extra editing controls receive their data back when the properties are saved. They can then be validated.

Once targeting is enabled (through having a value in the correct property) the IRuntimeFilter interface (which is a part of the IRuntimeFilter2 interface) is called to determine whether the web part should be displayed on the page.

The net effect of the personalization framework is that SharePoint can show or hide web parts to individual users or groups of users. This means that you can have a web part that is only displayed to operations team members (even if the rest of the organization has access to the data). Similarly you can surface or hide information based on the time of day, or any other criteria that can be tested.

This is a great strategy when you have a way that you want to be able to filter all of the web parts in the system. So showing different things based on location, time of day, or other criteria will work great. If you need to change what information is displayed in the web part – such as the weather for Carmel, IN vs. Daytona Beach, FL – this isn’t the strategy for you. Although you can show or hide a ton of web parts – one for each city. It’s really not practical.

Pages for People

Another, lower tech solution, which requires neither web part support for personalization nor the SharePoint targeting infrastructure is to have each user have their own page. With MOSS My Sites are available which do essentially this. Each user can have their own personal portal starting page. However, the challenge with this is that changes are hard to implement across the system. If each user has their own page just adding a new web part to the portal means adding one web part for each of your users – if you have 10,000 users you’ve just turned a simple change into 10,000 operations.

Still, the greatest flexibility is offered by having each user have their own page so that they have the flexibility to configure the page exactly as they would like – without concern for impacting other users.

Drawing the Target

In reality there may not be one answer to how you want to personalize your web part pages. In order to produce consistently relevant content to users you may need a variety of strategies. You might create different portal sites for each of the different departments so that users have the option to see content relevant to their department, implement My Sites for a personal view, and customize the home page so that the current weather conditions and predictions for the user’s current location are shown. There isn’t a single right answer to getting the right content to users at the right time.

Having a set of tools that allow you to filter and direct the information that users see is essential to driving relevance and therefore driving engagement in your portal. Go target your users.

Recent Posts

Public Speaking