How to use SocialTFS client
Figure 1 shows how SocialTFS client will look like in your Visual Studio IDE, once the configuration procedure here described is complete.
When Visual Studio is first launched after the plugin installation, you will see the SocialTFS client looking like the one in Figure 2 (remember, if you don’t see the view, you can show it by selecting it from the
View > SocialTFS menu).
We assume that you have received the email from the Proxy Server administrator for your SocialTFS installation. If not, contact the admininistrator or check your spam folder.
The information to enter are the following:
- Proxy server host – provided with your invitation email.
- Email – same address where you received the invitation.
- Invitation code – a one-time password, provided with your invitation email.
- Username – user defined.
- Password – user defined.
Once the registration step has been complete, you are ready to login (see Figure 3). Provide the same server host indicated in the invitation email, and the username & password that you chose in the previous step
After a successful login, the SocialTFS client will look like this, with a Metro-like UI, in which each tile represent a service enabled by the proxy server in use (Figure 4). A red square on the top-right corner means that you have not enabled that service
yet (in Figure 4, Yammer is not enabled). Services include either social network services like Facebook, Twitter and LinedIn, or TFS server installation. In the latter case, TFS installation can be a custom one – which must be enabled by the Proxy Server
admin, or the public TFS installation, called CodePlex, where Microsoft hosts open source projects.
Conversely, a green square indicates that you have enabled that service. By enabling, we mean that you have provided your authorization to the proxy server to access the service and retrieve some content (described in the next step). Where available, the
OAuth authentication protocol is used. This means that no access credentials are stored on the server, for privacy and security reasons. If OAuth is not available, as in the case of a TFS service, a login panel will popup, requiring user credentials to be
For the sake of privacy, for each enabled service, a user is asked to check what the proxy server is allowed to retrieve from, cache and display to other users (Figure 5). Features are service dependent. For instance, when enabling LinkedIn, the user is
asked whether to share its expertise list. Usually, is a good idea to always allow the proxy server to retrieve the list of friends, of followings/followers, in order to correctly build a user’s awareness network, and at least one picture from one of
the social network services.
To avoid cold start problems, SocialTFS incorporates a recommender system that suggests whom to follow (see Figure 6). To compute the suggestions, the recommender builds a weighted multigraph, whose nodes represent people and links represent connections
between them. A link is drawn from current user A to another user B each time one of the following conditions applies:
- B is in the same team project
- B is in another team project within the same TFS collection
- A is following B in a social network
- B is a follower of A in a social network
The links are weighted (default is 1), but weights can be changed to reflect that one of the conditions above is considered as more important than the others. For example, being in the same project may weigh more than being in the same collection of related
projects; likewise, following someone in Twitter may weigh more than being followed by the same person. Weight customization is left to the Social Proxy Server administrator.
When a user “accepts” a suggestion to follow someone, this becomes a static following, that is, (s)he will always be in the user’s awareness network and his/her updates will appear in the so-called home timeline, visible when selecting
the home icon in the toolbar (Figure 7). Here, also user’s own post will appear in chronological order.
Other than visualizing the stream of static followings in the home timeline, we also designed a
dynamic type of followings and two other timelines. Unlike static followings, dynamic followings do not require any explicit follow action, as they are automatically added to and removed from a user’s awareness network, depending on two different
conditions detailed below.
The first condition relates to changes occurring to the users’ assignments in the current iteration. Therefore, if for example Fabio reported or even commented on a work item assigned to Nicola, the latter will be able to see Fabio’s posts when
selecting the iteration timeline, visible when the clock icon is selected on the toolbar (Figure 8). The only considered work items are those in active or fixed state in the iteration at hand. Therefore, work items that have been already verified
or those scheduled for upcoming iterations are not considered when building an iteration timeline.
The second condition relates to actions performed by a developer within the Visual Studio IDE. In fact, the
interactive timeline, visible when the clock icon is selected on the toolbar (Figure 9) displays posts from dynamic followings as “inferred” from the artifact shown in the focused tab of the main editor of the IDE. Artifacts can be either
work items or source files. Therefore, if for example Peppe is editing a file that has been committed by Filippo, the latter will appear as a dynamic following when Peppe selects the interactive timeline. To speed up retrieval and visualization, the SocialTFS
client requests in background the dynamic followings for all the tabs opened in the IDE, so that when the user switches tab, the proxy has already cached the content to update interactive timeline content.