Steven Westwell’s blog

My outlook on a few things of interest to me, and hopefully you.

Posts Tagged ‘linkedin’

Unified Communications: Choosing the right method of communication

Posted by Steven Westwell on April 1, 2008


Nothing causes me more psychological pain in the morning than the outlook status message “updating inbox (3.35mb)”. On the up side this grants me the time to go get myself a coffee and some breakfast.

The last thing I want to do is wait for 20 minutes or more whilst outlook downloads a 2 or 3MB file, before I can read the rest of my email. It’s worse if I have only been a CC on a 2 or 3MB presentation or document sent to someone else for their review, and I don’t remember signing up to those 1MB weekly PDF newsletters I keep getting? 

I suppose it could be worse, it could have been an excel spreadsheet being sent to the team, and each team member may have responded attaching his/her copy with their comments and changes applied.  We will be tackling this situation in detail in the follow up posts on SharePoint Vs Excel.

Maybe I’m being a little unreasonable, this sort of thing happens en-mass in almost every company I have ever worked in. Basic computing lessons teach us how to use email and how to attach files, so why wouldn’t it be the most commonly done thing?

What can be done?

Email is one of the most inefficient ways to transfer files, and one of the quickest ways to utilise storage all over your enterprise. Typically each file sent via email exists a number of times within the enterprise, be it on your local machine in a PST file, your Mail server, your Enterprise Mail archiving solution or backups of any of the above. When you apply this logic to emails larger than 1MB it soon stacks up.

It’s no surprise then that one of the most appealing benefit metrics of collaboration & unified communication software is the reduction of email attachment sizes and enterprise storage requirements.  However user adoption is critical to the success of these factors.

If user adoption fails, what can we do by policy? well, we can always look to limit attachment sizes via exchange of course we then force the impact over on to the collaboration tools, however these are designed to manage such burdens via site quota, user quota & retention policies etc.

What can we do better?

As an individual however there is a number of things that can be considered when thinking about sending a communication

table of consideration

table of consideration

The above table only really works when you are considering a single factor, when you begin to combine them the decision over which medium to send your message becomes a little more complicated. 

Email: Often best placed when a reasonable size of message is required to be sent beyond that of “can you remember to send over your status report please?” or even for those smaller messages when the recipient isn’t online, lowest file sizes possible

IM: Typically much shorter than an average email, at least per message sent, sometimes transcripts of conversations can seemingly go on forever! These messages are usually conversational or consist of short one line notifications i.e. “do you have a minute to run through this spreadsheet?”, “yeah, shall we grab a coffee first?”.  Another useful feature of instant messaging is the ability to transfer files between two users, either Peer to Peer shared folders (as in Live Messenger) or one to one file transfers, these file transfers can also handle a reasonably sized file depending on your connectivity and the amount of time both you and the recipient will be online for.

Collaboration workspace:  interactive, known size of team / participants, drives process or aim for production of document(s) and collation of supporting materials, suitable for the majority of team focused documentation up to around 50mb. Blogs and wikis

Portal: basic interaction, large numbers of viewers, reasonably varied file sizes

Static Intranet: zero interaction, large numbers of viewers, any file size 

Phone: sometimes, just sometimes, its good to talk.

Moving between mediums

The more integrated your product set, the easier it is to shift between mediums. smart tags allow seamless integration between instant messaging presence information and a multitude of other products, using the Microsoft suite as examples, the smart tags can be found in office side panels, outlook To: and From: fields, sharepoint lists

When it all works well together the following little ramble of events is possible:

You could be editing a document in word and see the original authors presence information in the side panel or on the sharepoint site you are editing the document on.  You can click on their name and within seconds be instant messaging, a link to the document in sharepoint gets pasted or the document is shared in real time via application sharing… The conversation starts to flow a little and a couple of clicks later you can be in a Voice over IP call to their IM Client, desk phone or even Mobile phone.  All your changes are made and you save the document back to the sharepoint site, you set the status of the document to final in the document library’s meta-data and walk away…

The status change triggers a workflow, reviewers assigned to your document set are notified by email that a final version is available… they spot a couple of issues and want to talk to you about it via:

  1. Email including link to document?
  2. Email with document attached
  3. Collaboration tool?
  4. IM?
  5. VoIP/phone?

Questions and queries can often be made quickly and discussed easily via IM or Phone, if the user is not available, then mail is still a very good option.

Comments are discussed, the reviewer finishes their review but still feels more work is required, summary feedback is given via:

  1. Email including link to document?
  2. Email with document attached
  3. Collaboration tool?
  4. IM?
  5. VoIP/phone?

If the workflow has been set up as described above, it is fair to assume that further workflow will be in place to handle the feedback / approval process, probably with in built email notification. In order to ensure traceability of the review IM or Phone  are not necessarily persistent and many people use their inbox to drive their daily tasks, remembering a long since past conversation could cause confusion at some point.

I’m sure many of my future posts will include more thorough examples of collaboration scenarios and how they can be best utilised to improve employee performance.



Posted in Collaboration | Tagged: , , , , , , , , | Leave a Comment »

Isnt it odd…

Posted by Steven Westwell on March 26, 2008

…how some people check facebook more than email these days.

It’s a good thing from my professional point of view, but this is quickly becoming a blog post rather than the short facebook message I was about to send a friend.

More and more I find myself communicating with friends via facebook / social networking platform of choice or by reading RSS feeds from their blogs, or by a combination of both:

From a collaboration point of view, the indirect dissemination of information is fantastic, typically emails are only sent to those the sender thinks wants to see it, however with well constructed social networking platforms the readers can also choose to be told about such things happening in their relevant circles of interest. The obvious benefit of this is that the content is also readily available on a website rather than having to ask someone to forward an email.

Socially this change has been happening for some time, I rarely check my personal emails as most of the time I am contacted through IM or some social networking site that I check via RSS.

How soon is this to being reality for businesses? Microsoft being one of the biggest players in the workspace / productivity arena are making some distinct paths into this approach, SharePoint as a platform is extremely flexible, provides RSS feeds and readers by default and places much more control in the hands of users rather than that of the webmasters, allowing much more relevant content to be disseminated as described above.  Outlook 2007 now has an RSS reader built in, and various other interesting ways to view sharepoint content. 

Note: I am trying really hard at this point not to list out all the extremely cool functionality of both these product sets.

I know there are other players out there, but again, I do not want to go into too much depth and this point and wish to use MS as an example that almost everyone out there has heard of, and most have used MS Office in some shape or form.

So as we now enter the era of Windows Vista (with the release of SP1) and Office 2007 (well, why not if you are upgrading the OS?) will we see more and more take up of alternative communication methods? Probably, but this will not mean the end of email.

Growth of IM in the business is almost a certainty, as happened in the homes of many some time ago. 

Adoption of social platform like intranets, most probably, as we can see happening in peoples homes right now with blogs like these and the massive amounts of social networking users on facebook, myspace, live spaces, bebo, etc…

Email will more than likely than not stay on the table, and the previously mentioned alternatives should certainly not be viewed as replacements, they are complimentary products that provide more options that may often be better suited to the type of communication required for a given purpose than that of a typical email.

One of my biggest bugbears is the emailing of large documents and especially spreadsheets around a project team to “collaborate”, when web based workspaces are available that allow concurrent editing and dynamic viewing.

Again to use the Microsoft example, Excel spreadsheets -> SharePoint Lists.

There are some key benefits to converting excel spreadsheets to a sharepoint list when collecting information from several people, the lists can still be exported to excel for more advanced reporting options, but within sharepoint the concurrent editing, multiple views, event triggers and workflow type behaviour (and even RSS feeds of changes!) add a huge amount of functionality, especially when these types of documents are related to ongoing business processes.

I could even be monitoring all of this from outlook 2007 right alongside my email.

Once (and if) a final set of data has been created, I might IM the large file to a manager, or Email the file to a customer if I need a formal record and proof that it has been sent / received, and also allows for interoperability should they not be using IM or collaborative workspaces.

The signs are all positive that this will happen, and soon we will find those who have grown up with such technologies will easily and readily adopt them in a professional capacity, and greatly enhance their productivity.

Personally, I find this an exciting prospect and I begin to wonder what is next? what new toy will the next generation grow up with that will some day end up in the workplace? what technologies will make some everyday tasks practically dissapear and allow us to spend even more time delving into the important value add activities that hopefully offer some level of personal gratification, reduced learning curves due to wealth and structure of knowledge available.  According to Time Management courses I attended in the past, this could potentially offer reduced stress, better enjoyment of work and ongoing job satisfaction.

I’m sold 🙂

Posted in Collaboration | Tagged: , , , , , , , , , | 2 Comments »

OCS Localisation (ii)

Posted by Steven Westwell on February 26, 2008

So in my previous post, and over at Modality Systems we began looking at the localisation of Office Communicator 2007 to match the Office 2007 installation.  Over the last week I have updated the script to match the language of the OS.

However, this script is reliant on a task during the build of the client placing a variable into the registry.

Since we are using BDD (forerunner to MDT) and SMS OSD to deploy our client, we have several custom tasks and environment variables available to us during the build.  One of these is the “UILanguage” environment variable which contains the language pack to be installed during the build.  In the scenario we have this variable is populated by the BDD database depending on the role assigned to the particular client being built.

The following line of code writes the registry key that we query, this is run in the context of ztiutility.vbs, as a custom task created in BDD.: 

oShell.RegWrite "HKEY_LOCAL_MACHINESOFTWAREClientIdentificationVistaLanguage", oEnvironment.Item("UILanguage"), "Reg_SZ"

During the install applications phase of the build, following the install of both Office Communicator 2007 and the Office Communicator MUI pack, we execute the below code to localise Office Communicator

Dim iRetVal

On Error Resume Next
iRetVal = OCSLoc
On Error Goto 0

Function OCSLoc()Dim iRetVal
Dim UICode
Dim UILang
Dim strComputer
Dim oReg
Dim arrValueNames
Dim arrValueTypes
Dim strKeyPath
Dim i
Dim oShell
Dim FsoObj1

Const HKEY_LOCAL_MACHINE = &H80000001
Const REG_SZ = 1
Const REG_BINARY = 3
Const REG_DWORD = 4
Const REG_MULTI_SZ = 7
Const Success = 0
Const Failure = 1

Set FsoObj1 = CreateObject("scripting.filesystemobject")
set File_out=FsoObj1.CreateTextFile("c:logginglocationOCSLocalisation.log")

set oShell = CreateObject("wscript.Shell")

'//set default/flag values
iRetVal = Failure
OfficeCode = 1033

'// Check for the UI language and apply to OCS

File_out.writeline("zAZCFG-OCSLanguage: Looking for UI language ID in registry")

'//This script is executed following deployment from BDD/MDT via SMS OSD
'//During the deployment we tattoo the registry with the "UILanguage" environment variable
'//This is in the format en-US, fr-FR etc...

UILang = oShell.RegRead("HKEY_LOCAL_MACHINESOFTWAREClientIdentificationVistaLanguage")
'//Capture error
If Err.Number <> 0 Then
File_out.writeline("zAZCFG-OCSLanguage: Office Language Key not found, defaulting to: en-US")
oShell.RegWrite "HKEY_LOCAL_MACHINESOFTWAREMicrosoftCommunicator MUIDefault Language", 1033, "REG_DWORD"
iRetVal = Success

Set FsoObj1 = Nothing

Exit Function

End if

File_out.writeline("UI Language Identified as: " & UILang)

'// Convert Language to LCID i.e. en-US -> 1033 for all supported languages

Select Case UILang
Case "en-US"
UICode = 1033
Case "nl-NL"
UICode = 1043
Case "fr-FR"
UICode = 1036
Case "de-de"
UICode = 1031
Case "it-IT"
UICode = 1040
Case "ja-JP"
UICode = 1041
Case "es-ES"
UICode = 3082
Case "ar-SA"
UICode = 1025
Case "zh-CN"
UICode = 2052
Case "zh-HK"
UICode = 3076
Case "zh-TW"
UICode = 1028
Case "cs-CZ"
UICode = 1029
Case "da-DK"
UICode = 1030
Case "fi-FI"
UICode = 1035
Case "el-GR"
UICode = 1032
Case "he-IL"
UICode = 1037
Case "hu-HU"
UICode = 1038
Case "ko-KR"
UICode = 1042
Case "nb-NO"
UICode = 1044
Case "pl-PL"
UICode = 1045
Case "pt-BR"
UICode = 1046
Case "pt-PT"
UICode = 2070
Case "ru-RU"
UICode = 1049
Case "sv-SE"
UICode = 1053
Case "tr-TR"
UICode = 1055
Case "bg-BG"
UICode = 1026
Case "hr-HR"
UICode = 1050
Case "et-EE"
UICode = 1061
Case "lv-LV"
UICode = 1062
Case "lt-LT"
UICode = 1063
Case "ro-RO"
UICode = 1048
Case "sr-Latn-CS"
UICode = 2074
Case "sk-SK"
UICode = 1051
Case "si-SI"
UICode = 1060
Case "th-TH"
UICode = 1054
Case "uk-UA"
UICode = 1058
Case Else
UICode = 1033
End Select

File_out.writeline("UICode set to: " & UICode)

If UICode > 999 and UICode < 10000 Then

File_out.writeline("zAZCFG-OCSLanguage: Writing language code to OCS key: " & UICode)
oShell.RegWrite "HKEY_LOCAL_MACHINESOFTWAREMicrosoftCommunicator MUIDefault Language", UICode, "REG_DWORD"
iRetVal = Success


File_out.writeline("zAZCFG-OCSLanguage: Language Key not valid, defaulting to: en-US")
oShell.RegWrite "HKEY_LOCAL_MACHINESOFTWAREMicrosoftCommunicator MUIDefault Language", 1033, "REG_DWORD"
iRetVal = Success

End If

Set FsoObj1 = Nothing

OCSLoc = iRetVal

End Function

Posted in Collaboration, vista | Tagged: , , , , , , , , , , | Leave a Comment »

OCS Localisation

Posted by Steven Westwell on February 21, 2008

As mentioned by John Lamb in his blog over at Modality Systems, we have been looking into automating the localisation of Office Communicator client.

After a bit of thought it seems most obvious to match the language of Office Communicator to the operating system language rather than Office, however before this happened I put together the following code to match the office communicator client to office 2007:

  If Err.Number <> 0 Then
   ologging.CreateEntry "zAZCFG-OCSLanguage: Office Language Key not found, defaulting to: en-US", LogTypeInfo 
   oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Communicator MUI\Default Language", 1033, "REG_DWORD"
   iRetVal = Success
   If OfficeCode = 1033 Or OfficeCode = 2052 Or OfficeCode =  1043 _
    Or OfficeCode = 1036 Or OfficeCode = 1031 Or OfficeCode = 1041 _
    Or OfficeCode = 1042 Or OfficeCode = 1046 Or OfficeCode = 3082 _
    Or OfficeCode = 1028 Or OfficeCode = 1030 Or OfficeCode = 1035 _
    Or OfficeCode = 1040 Or OfficeCode = 1053    

    ologging.CreateEntry "zAZCFG-OCSLanguage: Writing language code to OCS key: " & OfficeCode, LogTypeInfo 
    oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Communicator MUI\Default Language", OfficeCode, "REG_DWORD"
    iRetVal = Success
    ologging.CreateEntry "zAZCFG-OCSLanguage: Office Language Key not supported in OCS MUI, defaulting to: en-US", LogTypeInfo 
    oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Communicator MUI\Default Language", 1033, "REG_DWORD"
    iRetVal = Success
   End If 
  End If 

oshell is a windows shell object and ologging is a ZTIUtility file writing parameter.

In the near future I will update with a script to set office communicator to match Vista 🙂


Posted in Collaboration | Tagged: , , , , , , , | 2 Comments »

Another Japanese Keyboard update – Fix

Posted by Steven Westwell on February 20, 2008

Following up directly on the previous post, the following vbscript should add the required registry values for the japanese keyboard driver to be used by the Japanese IME:

Option Explicit
Dim ReturnValue
ReturnValue = FixJPKB()

Function FixJPKB()
DIM iRetValue
Dim WshShell

set WshShell = CreateObject("wscript.Shell")

WshShell.RegWrite "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters\LayerDriver JPN", "kbd106.dll", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters\OverrideKeyboardIdentifier", "PCAT_106KEY", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters\OverrideKeyboardSubtype", 2, "REG_DWORD"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters\OverrideKeyboardType", 7, "REG_DWORD"

Set WshShell = nothing

End Function


Since this looks like it may also affect non Japanese IME’s I will update following some tests in case handling of the Korean keyboards is required or if this affects alternate IME’s

Posted in Japan, vista | Tagged: , , , , , , , , , , | Leave a Comment »

USB Japanese Keyboard Driver issue (with Vista)

Posted by Steven Westwell on February 19, 2008

Following up on my previous post about selecting the correct driver for the Japanese IME, the following microsoft kb article shows how this issue can come about with USB keyboards, and how to edit registry values to select the right driver:

Posted in Japan, vista | Tagged: , , , , , , , | Leave a Comment »

Japanese Keyboard on Vista

Posted by Steven Westwell on February 6, 2008


so as part of our global deployment of Windows Vista, we found that the Japanese users of the Japanese IME had an issue with the keyboard layout being incorrect.  The hirigana, Katakana and romanji where correct for the most part, however the symbols “, @, (, ) and * etc were in the US locations, not as they should be on a Japanese keyboard.

Others in the UK will be familier with typing <shift> + 2 expecting ” and getting @, well this is the same thing fundamentally, just complicated with the IME layout not being something that can be switched by the users locale.


After digging around I managed to find a few excellent posts on this problem and showing the solution for Windows NT, 2000, XP etc… It would appear to be one of those consistent issues that has been with the OS for a long time.

It was enough to point me in the right direction and I thought it was only fair to post the Vista specific solution here.

The problem is the IME seems to get its keyboard layout directly from the keyboard driver, rather than the keyboard locale settings that typically control layouts.  In order to fix this the Japanese keyboard driver must be selected manually.

below are the step by step instructions for an english OS, I may attempt to translate into Japanese soon, or at least include screenshots from a Japanese client to show the dialogue boxes:

  1. Open the Device Manager
    1. Open the start menu
    2. Right click on computer
    3. Select manage (Entering PA account details when prompted)
    4. Select device manager
  2. Change the Keyboard Driver
    1. Open the keyboard tree
    2. Right click the keyboard
    3. Select “update driver software…”
    4. Select “browse my computer for driver software”
    5. Then select “let me pick from a list of device drivers on my computer”
    6. Uncheck the “show compatible hardware” checkbox
    7. Then choose the (Standard Keyboards) as Manufacturer and Japanese PS/2 Keyboard (106/109 Key) as Model
    8. Then select next
    9. The driver will then be installed, then click close

After the next reboot the default layour will be the Japanese layout, and the ” symbol will be in the correct place when using the Japanese IME.

Thanks to:

Cameron Beccario: /


Michael Eng:

Cameron’s blog was an interesting read, and also lead me to find a very cool and interesting to read about Japanese language school:



Posted in Japan, vista | Tagged: , , , , , , , , , , | Leave a Comment »