Tools – The Budding Techcomm Blogger

The Dreamweaver project

At the start of this blogging assignment, I decided I would do a review of Dreamweaver and what shall forever be known as “the Dreamweaver project”. Two months later and twelve days before the Dreamweaver project deadline, the best review I can come up with is that Dreamweaver and HTML/CSS coding are an apt metaphor for the difference between understanding and doing.

The background

The background is simple. We created a storyboard for a small website. Now we have to develop this website in Dreamweaver. I have never designed a website nor used Dreamweaver before. I have enough knowledge of HTML and XML to understand most of the code when I read it. I thought that knowledge, access to w3schools.com, and more online research would be sufficient. How naive!

The process

I am now on my third attempt. First, I tried to create the website from scratch. The most accurate description for this attempt is a big, sarcastic “LOL”. Anyway, my template was almost correct, but I was stalling, I did not see how to untangle the situation, and I had to expect as much trouble with every feature I created.

I proceeded simultaneously with my second attempt (building the site as a table) and third attempt (using the only vaguely similar Dreamweaver template available) to see which one would be more efficient to handle. The Dreamweaver template won. My template index.html is not perfect, but I can improve it later on. For now, it’s functional and I have to move on.

Still, I have to downgrade my ambitions for this project from my storyboard. I asked my brother for his opinion on my storyboard because he is experienced in coding and web design. He is that person who will answer your questions with an obnoxious “Oh! That’s so obvious! Just do [something that is definitely not obvious].” So, hearing him say “You couldn’t start easy, could you?” was a relief.

I have had this feeling that expectations for this project are too high. Designing the storyboard with skewed expectations of my abilities, the learning curve, and the usability of Dreamweaver set me up for a world of failure and frustration.

Understanding vs doing

Like with any language, understanding the HTML/CSS code of a website and “writing” a website are two massively different things. My usual strategies for learning to write in a language would broadly include:

Mastering the rules (grammar, syntax, keywords, etc.)
Reading as much as possible to increase my vocabulary and internalise a natural writing style
Writing content using what I have mastered and increasing complexity progressively

Based on my experience so far, coding is different from most languages I learnt before. There may be several, slightly different ways to code the same feature, but I find beginners have less freedom for creativity than with other languages.

For example, when in my third year of Russian, I had to write complex text analyses with a limited vocabulary, a pocket dictionary, and no Internet. As a beginner, I had to find ways to express myself with these limited resources. I had to rephrase my thoughts in simpler terms or terms that I could access. This is one of the hardest exercises I have ever done, but also one of the most useful for communication and learning in general.

I have tried to reproduce this process with this project without success despite access to incredible resources. I improve by small increments but reviewing how I solved each issue, I find that I solved my biggest issues through pure luck instead of identifying the root causes. I am trying to improve my skills by monitoring and analysing my progress, but I cannot consider luck as progress. A crucial piece is missing and I think it is a deeper understanding of HTML, CSS and web design rules, like how each coded feature interacts with the rest of the code. I would need a lot more time and overseen practice through e-learning courses for this.

Conclusion

No doubt the Dreamweaver has provided an opportunity for deeper learning, forcing me to evaluate and adapt my strategies. Unfortunately, the main strategy I can think of is to spend more time learning about the code and Dreamweaver through e-learning courses, but time is not an option anymore.

How much time would I need? My summer development project is coming up and I am supposed to build a much more complex website with Dreamweaver and WordPress. I have to keep in mind the overall development project and my priorities – the first is content design of a learning resource for the web, the second is WordPress hosting. The tool used is a secondary consideration. There’s the lesson of the Dreamweaver project.

That’s all, folks!

Virtual Team Project – Wrap-up

Our virtual project came to an end on Monday 25^th March with the delivery of our English instructions and their French translation. Let’s wrap this up with a look back at Team 2s.

The project

Team 2 had ten members at its disposal to create and translate up to 1,200 words of instructions to help a non-technical audience to carry out a simple task in an online tool. With all team members having to maintain a blog during the semester and after agreeing that WordPress is less than intuitive for first-time users, the team set out to write instructions for beginners who want to set up their first blog in WordPress.

Team communication

Aren’t ten people a bit much to write and translate 1,200 words? Probably, but the point of the project was virtual collaboration. Collaborating with nine other people is challenging no matter the project. this was evidenced by our inability to find a suitable time for a single live team meeting over eight weeks.

If we were working full-time on this project, I would have expected my teammates to find the time for a live online meeting. But, on top of being spread out over four time zones, we all had jobs, studies, and other commitments to juggle. So, I did not push the issue. We already had the WhatsApp chat for live, on-the-go communication. I did not want to risk alienating one of our team.

That being said, I recognise that a live meeting would have been beneficial to break the ice and adjust our communication styles. Body language can be misleading, but it provides cues faster than written or phone communication. Instead, like most of the team, I tried to share about myself little by little in my messages, for example about other on-going assignments, and I brought in some emojis, but only the standard ones (smiling, laughing, crying) in non-ambiguous situations to avoid misinterpretation.

Another advantage of live online or face-to-face meetings is that they speed up decision-making. Live meetings with an agenda greatly improve productivity and certainty: people engage to make binding decisions in a defined timeframe. Only smaller details may need adjusting later through email or chat. I learnt that collaborating mostly through an online chat is more time-consuming, especially in our specific setup (see above). Sometimes, I had to “chase” members to get their input on a group decision. Did they not care or were they genuinely busy? I found gauging situations in an online chat even more arduous than in emails.

In general, I tried to stay positive in all our communications. Everyone will encounter difficulties, make errors and become frustrated at some point during a project. I have always found that I need to take a step back to re-frame my frustrations in a positive light. Despite the sense of urgency I feel when using WhatsApp, I forced myself to wait before answering messages, to try to rephrase my messages and consider other points of view. I used to do this as project manager, but I have not had to practise it as much as a translator, so I had to pay particular attention to knee-jerk reactions.

I also tried to point out our team’s progress regularly, focussing on all we had achieved and how “little” was left. I hoped this sense of achievement would maintain a positive mindset. Other team members also used this strategy, so I assume it resonated with them.

Leadership

I have been working in virtual teams for about ten years now, as project manager and translator, so I may have been more prepared than other teammates. However, I think no one is ever really completely prepared because each experience depends on the other virtual collaborators involved and the context.

As a translation project manager, my projects did not use to require all team members (vendors, salespeople, and clients) to interact. All communications and decisions went through me. This experience was quite different. Here, we were all collaborating live on WhatsApp and Google Drive. In addition, despite a variety of backgrounds and expertise, I felt that we were all qualified to give our input on all aspects of the project because this was the first experience for all of us. So my role was closer to a moderator, starting discussions, offering suggestions and trying to reconcile everyone’s input.

We had very few disagreements, which we resolved through votes if there was no single correct solution. However, I wonder if this means we were all in agreement with my suggestions, or if my teammates either thought I knew better from my experience or chose not to make their own suggestions. Given our context, I could understand the latter option. I just hope it was not the first option as I made sure to explain my approach several times.

The process

Writing

The writing team decided on a combination of alone work and collaboration. Within one weekend, we had the first draft with input from the four writers. I was not expecting this strategy, but it worked well for us. Each writer was able to feed on available content and to add their own input while keeping their own style. No one had to dedicate more than a few hours of their busy schedule and the writers could compare styles and make informed decisions on the most appropriate one.

I see how this strategy could easily become messy in a large scale project if an official writing style has not been agreed yet. However, I find this strategy was an effective way to play around with writing styles and learn from others. Also, it made each writer into a researcher and tester who had to go through the previous writers’ inputs before starting. No, the content was not 100% accurate in the first draft, but close. So, I think this strategy was a good decision from our writers for this project.

Then, over the two following weeks, the writers edited various drafts and I asked the whole team, including the translators, to give feedback to the writers. Given the pressure on the team to have the English instructions ready in about two weeks, I thought that having everyone’s input would be beneficial for the writers. Other team members were helpful, including the translators who noticed some inaccuracies. However, after a few editing loops, we started stalling. In hindsight, I would rather the writers edited and proofed in isolation until the final draft was ready for testing and final quality review. The QA team would have had a fresh look unencumbered by pre-existing knowledge.

Localisation

The translation process was quite smooth, at least from the English team’s point of view. One of the two translators acted as the main point of contact, and no questions or issues were pointed out in the English text. That is, there were small formatting issues that the translators corrected in the French, but they did not inform us despite our asking several times. Thankfully, it was nothing that our last proofreading would not have highlighted, but I am not sure what I would do to prevent this in future projects for non-obvious issues with a language unknown to me. I can only think of having a separate bilingual editor, one who has not worked on the translation.

This lack of communication during translation was disappointing because I explained to the translators how their input would be beneficial for the English text and for their teammates, and that non-translators would likely want to talk about translation in their blog posts. And one of the translators was active in our chats while we were writing the English text. I know this lack of teamwork is a common gripe among people working with translators, so I was disappointed that we did not lift the curse in our team despite communicating our expectations.

Finally, graphics localisation reminded me not to take my knowledge for granted. For me, it was obvious that localised graphics should look exactly like the source graphics and that graphics text should never be translated separately from the rest of the translation or using different resources. As both situations happened during the project, I realised that I had made assumptions based on my experience. I remember discussing the first issue during my translation degree and I know that non-translators may not be aware of the second issue. But this knowledge has become second nature and I forgot for a second that it is not universal. I will have to be more careful about this in the future.

The tools

Apart from Microsoft Word, we used three tools, Google Drive and Google Docs for storing and editing files, and WhatsApp for communication.

Google tools

Google Drive is a handy tool for sharing content. It took a second to master the sharing options. Other than that, I only have good things to say about it. The layout is clear, navigation is easy. We did not have any bugs. Google Drive kept its promise. Great!

Google Docs is another story. Overall, it is easy to use and intuitive, though I struggled to find some formatting options and it is not as rich as MS Word in terms of formatting. But the biggest issue is that it is prone to random formatting changes during editing and, if you implement formatting in Word and then open the Word file in Google Docs, some of the Word formattings will be corrupted and it will not be reinstated once you download again to Word. This means that once we implemented the final formatting on the instructions, we could not use Google Docs anymore.

Dropbox did not seem to have these issues for other teams. One Drive with Word 365 online might also be a good alternative if everyone can access it. I would be interested to collaborate either on Dropbox or One Drive to test whether they are efficient collaboration tools.

I never used WhatsApp professionally, so I was anxious about that. I always keep my personal content off my professional tools and emails, so I was uneasy having both personal and professional chats hanging out next to one another. Nothing to hide, but also no valid reason to have both in such close proximity. For one, in the moments where I decided to rest my mind from work or studying, I did not enjoy receiving this project’s notifications while I was talking to friends in another chat.

Another issue was that discussion and decision-making were very messy at the beginning. So much to decide! Do we keep all topics in one group chat or do create several chats for each topic? In a tool like Slack, I would definitely go the route of “1 topic = 1 chat”. In WhatsApp, we kept one chat and nobody even suggested splitting topics in different chats. I suspect mayhem would have ensued. Instead, in the same chat, I would start a topic with a long summary message and I would try to have one message per question so that other members could use the Reply message option to answer a specific topic/ question. Then I would summarise the decisions we agreed on.

The first ten days or so, I maintained chat minutes every day. This is when we had the longest discussions and I thought a summary of who proposed what and what decisions we took would be helpful. Members would not have to go through the whole chat thread then. I abandoned those minutes once our chats became shorter and focused on editing feedback. I kept using the long message structure, so anyone looking for new questions or decisions could look for these messages specifically to get a summary of discussions and decisions.

WhatsApp is not all bad. It allows for more informal communication and for resolving issues on the go. However, for me, it is not adapted to the professional follow-up of a project. I have never used a tool like Slack or Basecamp. Students in other teams used them and had good feedback about their usability and the learning curve, so I would like to try one of them in a future project.

Conclusion

Would I want to work in a virtual team again? It is very likely to happen given the nature of technical communication and the rise of remote work. Based on this experience alone, I have nothing against virtual teamwork in itself. Having worked in both virtual and face-to-face configurations, the main challenge really is the lack of cues that help to gauge a situation, like body language and tone. If you always work with the same team, this challenge fades progressively, especially with live online meetings. Otherwise, I find the configuration no less efficient than face-to-face teamwork as long as you have the right tools to facilitate collaboration.

Back in the Saddle?

Virtual Team Project – Week 1

So, here’s the deal. My fellow Limerick students and I have to participate in a virtual collaboration project with students in Orlando and Paris. Together, we need to write instructions for an online tool and then translate these instructions into French. That does seem in my wheelhouse… This past week was all about getting to know each other, assigning roles, and deciding the basics of our communication and management processes. Simple, right? Not so much when you have ten people spread over three countries and as many universities.

We saw quickly that we would not have a live online team meeting this week and we would have to rely on emails until everyone joined our Whatsapp group. Long email threads are not ideal, though they were the norm where I was a project manager so I might be more comfortable with them than my teammates.

I am a bit anxious at the thought of Whatsapp being our main means of communication. May I remind you that there are TEN of us? Have you ever tried to organise anything online with more than two people? Don’t get me wrong, a group chat is great: because it is informal, people may share their thoughts more freely. But is it adapted for structured communication and for making decisions? In my opinion, email or any other structured form of communication is still required to keep the focus on set objectives. One option: I may recap the chat daily (or as needed) to summarise what came of it.

Yes, I am the team’s project manager. That was not my intention as I thought the role could provide a useful experience for someone else. I had my eye on a localisation consultant/editor role. Eventually, I did take over planning this week and though I offered to step back, my teammates agreed to leave me this role. In my previous experience, the rules were more clear-cut – I made the decisions based on data from all the project stakeholders (internal client stakeholders, translators, proofreaders, post-localisation designers, reviewers, etc.). In this project, I think we will all benefit from having everyone participate in the decision-making process. So, the main challenge for me will be to foster structured individual engagement – in Whatsapp. Let’s see how this goes.