Behind the Curtain at TCG

Telework Exchange to Host Complimentary Webcast

The Telework Exchange, an Alexandria-based public-private partnership focused on demonstrating the tangible value of telework and serving the emerging educational and communication requirements of the Federal teleworker community has announced that it will host a complimentary Webcast titled "Ramp Up Your Savings: Measuring the Telework Returns" on May 17, from 1:00-2:00 p.m. EST. The webcast will focus on how to identify key factors that contribute to telework return on investment and how to develop effective measurement methods. Agency representatives will discuss measurement techniques as well as management and technology considerations to address when determining telework effectiveness. Panelists will also share best practices in how to leverage cost savings and avoidance to build the business case for telework--highlighting results through real estate, utility, and commuter savings in addition to reduced recruitment and retention costs. For more information and to register click here.

TCG Ranked #23 on 2012 Inner City 100 List

The Initiative for a Competitive Inner City (ICIC) and Fortune Magazine have named TCG as one of the 100 fastest-growing inner city companies in the United States. The Inner City 100 program recognizes successful inner city companies and their CEOs as role models for entrepreneurship, innovative business practices, and job creation in America’s urban communities. TCG is ranked 23rd on this year's list and this is our third consecutive appearance on the list having ranked 37th in 2010 and 17th in 2011. To read the full press release click here.

Telework Exchange Announces Telework Week Results

The Telework Exchange,an Alexandria-based public-private partnership focused on demonstrating the tangible value of telework and serving the emerging educational and communication requirements of the Federal teleworker community, recently announced the results for Telework Week 2012, an effort that encouraged employees to telework during the week of March 5-9, 2012. This year's results found that Telework Week 2012 participants saved a total of 6,413,006 miles; 251,774 hours; 3,453 tons of pollutants; and collectively saved $5.6 million by not commuting. For more informaton and to download the report, click here.

DATA Act Sets Taxpayers Against Grants Recipients

The National Grants Management Association reports that the Digital Accountability and Transparency Act of 2012 (commonly referred to as the DATA Act) is speeding through Congress. This is good news for taxpayers -- it mandates that Federal grantees and contractors at all levels report on how they spent the money they received from the government. But it's going to cut services. The problem: no funding for the new reporting requirements. So Federally supported programs are going to have to take money from the services they provide in order to comply with the law.

The act,H.R. 2146,and a summary are here.

Lack of Documentation a Common Audit Finding

"Most A-133 audit findings relate to inadequate policies and procedures," according to Wayne Finley of the St. Petersburg, FL, mayor's office. 

Finley was a featured speaker at the recent National Grants Management Association national conference here in the DC area. He listed the common audit findings, which included a host of items related to documentation:

• Failure to prepare a complete and accurate Schedule of Expenditures of Federal Awards (SEFA)
• Lack of competitive bidding documentation
• Progress reports not filed on time
• No separate set of expenditure ledger accounts to exclusively record grant program expenditures 
• No personnel activity reporting system
• No signed time sheets
• No written approval for changes in key staff
• No documentation of fringe-benefit expense or rate
• No documentation or sole-source justification for consultant or equipment contracts
• No written contracts with consultants
• No documentation of expenditures for grant supplies

Lack of documentation is not just a deficiency for audits, where if you don't write it down it's as though you didn't do it. Lack of documentation means that even if you do everything right, it's not repeatable because you don't know exactly what you did last time. Documentation is what makes best practices repeatable. If you don't write it down, how can you be sure you will do it the right way again next time (or remember what you did wrong last time)? Documentation is a good thing whether or not you are being audited.

 

TCG’s Judith Turner Elected to NGMA Board of Directors

TCG vice president Judith Turner has been elected to the Board of Directors of the National Grants Management Association (NGMA). Ms. Turner and seven other new board members were voted in by NGMA’s membership at NGMA’s annual training conference, which was held April 22-25 in Alexandria, VA. TCG is proud to support NGMA as a Director Level Corporate Sponsor. To read the full press release click here.

TCG’s Nina Preuss Is a Women In Technology Leadership Award Finalist

TCG project manager Nina Preuss has been named by Women In Technology (WIT) as one of 49 finalists for its 13th Annual Leadership Awards. The awards honor women who have excelled as mentors, leaders, and role models in the Washington, DC technology industry. Ms. Preuss is one of five finalists in the Public Sector (Small Business) category. To read the full press release, click here.

Project: Facebook Data Liberation - Part 4 - Reading Feeds

Back in Part 1, I explained why I'm making this HTML5 application. The condensed version of the story so far is that I'm making is a web/mobile app that can read a running/fitness Facebook group feed. Now we are up to Part 4 where I will show you how to pull a group feed using JavaScript.

I want to get all the feed data for the group.  Since there are more than 1000 posts, I can't just grab everything in one pass.  Instead I will be using the "since" and "until" parameters to break the posts up by time.  For the Facebook API, you specify the since/until using a Unix timestamp, which is pretty much just the number of seconds since January 1, 1970.  Here is a JavaScript snippet to set two timestamps, one for now and one for 30 days ago:

var date = new Date;
var timeend = parseInt(date.getTime() / 1000);
var timestart = timeend - (30 * 24 * 60 * 60)

You can see that I need to divide the getTime() call by 1000.  That's because the JavaScript Time uses miliseconds since Jan 1, 1970 rather than seconds.    

Now that I have the start and end time, I will use jQuery to make an Ajax call to get the feed:

function getBatch() {    
    var accessToken = window.location.hash.substring(1);    
    url = "https://graph.facebook.com/YOUR_GROUP_ID/feed?limit=500&since=" + timestart + "&until=" + timeend + "&" + accessToken;    
    $.ajax(url, { complete: parseFeed });
}

function parseFeed(jqXHR, textStatus) {    
    var data = $.parseJSON(jqXHR.responseText);   
    displayData(data);    
    timeend = timestart;    
    timestart = timeend - (30 * 24 * 60 * 60) ;   
    if (timeend > stop_here) { getBatch(); }
}

When getBatch is called it will build up a URL and then make an Ajax call to Facebook.  The URL for that call is constructed as described in Part 1, but the API is simple enough that you can probably tell what each parameter does just by looking at it.  When the Ajax call returns with the data, parseFeed is executed.  You can see that parseFeed does three things:  First it reads the data.  Second, if moves the start/end timestamps back another month.  Finally, if the timestamps haven't gotten back to my hard coded "stop_here" timestamp, it will call getBatch again to grab the next set of posts.

This is a simple way of paging, and it works fine for my group because I know that I can retrieve all the posts in a time window with one call.  A production level getBatch/parseFeed pair would use the previous and next page URLs that Facebook provides as part of the feed.  I'll leave that as an exercise for the reader for now.  That is pretty much all the "moving parts" for my project.  I have a prototype working and it's doing exactly what I want.  Right now the code is locked into working with a particular group, and it only does two small things: list all the posts in the group and make a guess at the number of miles run by group members.  The next step is taking a critical look at the whole thing and deciding if I should try to build this out into a "real" app that anyone can use.

Embracing the Tag Pattern on Social Sites

I've conditioned myself to use keyboard shortcuts whenever possible.  I think it's a lot faster to keep your hands on the keys whenever possible.  When I'm trying to help someone with a computer problem, though, I stay quiet about how this or that keyboard shortcut is faster than using the menu. In a best case, it just ends up distracting us both from the issue at hand.  In the typical case I come off sounding impatient and obnoxious.

I had resigned myself to the idea that people are going to use the mouse to do everything...but then, something happened.  I didn't realize it for quite a while, but regular every-day people are using what amounts to a keyboard shortcut to tag people and pictures in Facebook all the time. In a Facebook post, if you type the @ symbol and start typing a name, the web page will pop up a small drop down showing all your friends with those letters in their name. 

This is kind of sneaky because it's not a traditional keyboard shortcut.  You don't use the control or alt keys and it doesn't use "those crazy keys at the top of the keyboard" that no one knows how to use properly.  Facebook just co-opted a symbol people are accustom to typing.  Not only that, they used social feedback to encourage people to add valuable metadata to their postings.

The Twitter culture has a similar thing with their hashtags.  If you want a tweet about a topic to be easily findable via search, you put a hashtag in with your text.  (A hashtag is just a # symbol followed by a keyword.)  Twitter doesn't give you any indication you did something special when you press the # key, nor does it suggest a list of common hashtags as you are typing the way Facebook does.  But when you view a tweet with a hashtag, it becomes a clickable link to a list of other tweets using the same tag.

So these two sites have conditioned users to add searchable metadata to their posts directly in the text content.  This is great!  You can see the same behaviour all over the place now.  Of course Google+ does it, but I didn't know until last week that Google Docs does it too.  If you add a comment to a document you can @tag it to someone you are sharing with and they get a directed email with your comment.

If you are one of the exclusive group of people following my blog posts, you know I am working on a small Facebook web application for fun.  One of the challenges I have in that app is parsing out human written text from a group feed to get info on how many miles a person ran that day.  This is a perfect place for a special metadata indicator.  If I could convince the community to put a # or & or * before their mileage my problem would be solved!  

For example, this is very hard for a computer to parse:

Ran 5 on the Boardwalk at a 10 minute pace.

In the right context, another runner knows exactly what that means...but a computer parsing hundreds of posts can't be so sure.  On the other hand look at this post:

Ran *5 on the Boardwalk at a 10 minute pace.

As long as everyone agrees that adding the * before a number means miles run, then it's an easy text processing problem.

So the next step is how to get people to use it. One of my favorite sites, StackOverflow, encourages user behavior by fading in a small colored box to the right of some forms.   The contents of the box changes dynamically when they have new instructions (or warnings) based on what you are typing.  I can imagine a mock up something like this:

If you want to encourage its use, you should give users immediate positive feedback when they use use a tag to provide metadata.  It could be something as simple as highlighting tagged text in green to indicate they did it correctly.  If the web site owner is the only one benefiting from the metadata, it's going to be a very hard sell to train your users.  On the other hand, if you build useful features on top of the tags, features that directly benefit the people doing the tagging, then I expect you will see good adoption rates. 

Project: Facebook Data Liberation - Part 3 - Authentication

Back in Part 1 I explained why I'm making this HTML5 application. The condensed version of what I'm making is a web/mobile app that can read a running/fitness Facebook group feed. In the Part 2 I explained how I was going to process the group feed once I got it.  In this part I will show you how to authenticate with Facebook and download the data into your web app.

There are a few ways to work with the Facebook API in a HTML5 application.  You can use their JavaScript SDK, you can do the integration on the server side, or you can make direct calls with your own JavaScript functions.  I'm going to use that last technique.

The basic process works like this:

1. The user loads your web page
2. JavaScript on the page checks for a Facebook authentication token.
3. If the token isn't found, JavaScript will redirect your user to the Facebook login URL, (https://www.facebook.com/dialog/oauth) with certain GET parameters
4. The user logs in  and Facebook redirects them back to your application with the authenticaion token included in the URL
5. JavaScript in the application examines the URL and finds the auth token indicating a successful login

I mentioned in step 3 that there are parameters you pass into the Facebook auth system.  Here are the ones I use:

• redirect_uri - this is the URL that Facebook will use to send the user back to your application
• response_type - this can be set to a value of "token" or "code".  A value of code is used for server side authentication.  Since we are building a stand alone HTML5 app, we will use token.  When Facebook redirects the user back to your page, it will append a #access_token=XXXXXX to the URL so you can read the token from the location.
• scope - This is how you request certain privileges for your token.  Since our app needs to see group information, we will request "user_groups".  If you need to get more privileges, use a comma separated list.  Facebook docs have the complet list of privileges you can request.

The documentation lists the other parameters you can use, but that's all we need for this application.

That's the outline, here is the code I am using:

var appID = 'YOUR-APP-ID';
if (window.location.hash.length == 0) {   
    var path = 'https://www.facebook.com/dialog/oauth?';   
    var queryParams = ['client_id=' + appID,     'redirect_uri=' + window.location,     'response_type=token', 'scope=user_groups'];
    var query = queryParams.join('&');
    var url = path + query;
    window.location = url;
} 

Using this code as-is will automatically send the user to the login page.  A good UI would have some kind of warning or login button to press before that.  Every app will want to do that differently, so pick the method that is right for you.

If you look at the code above, you see that an application ID is needed.  You can get this by registering your application on the Facebook developer app: http://developers.facebook.com/setup/

One important note, when you register you have to list the Website URL of your application.  When you try to use the Facebook API, your referring URL (or at least the domain) will be checked against the value you put in there.  If things don't match up, you will see the message "An error occurred.  Please try again later."  on the Facebook login screen.  Clearly not very helpful to a developer, but I guess it's better for your end users to see that than something like "The developer of the web app you are trusting with your personal Facebook data isn't smart enough to code it properly and here is what he/she did wrong: XYZ"

The name restriction makes local development a little trickier than most HTML5 applications.  This means you can either do your development on a public web server or setup and match a DNS entry for you local system with the URL you register with Facebook.  

This is a bit annoying for me as my local system is a Windows 7 box without a web server installed. I could do my coding on my Linux server I have on Amazon's EC2, but I really like Visual Studio as an editor.  My solution was to use Server2Go as my local web server and register my home router's public name as my website URL with Facebook.  When I'm ready to deploy my app to the world, I will update my URL with Facebook.

In the next part, I will talk about pulling the feed pragmatically and parsing the data.