Home

The Advantages of Collaborative Interaction Design

cassie.mcdaniel@ldschurch.org (Jed Grant) — Tue, 14 Jul 2009 21:29:42 +0000

Usually an interaction designer works to understand and implement project requirements in a way that allows users to most effectively accomplish their tasks. In this model, team members review designs and offer feedback, which leads to valuable improvements in the product design. Various iterations with the team happen before the design is even presented to the client.

When you present the design to the client, the client usually requests additional changes, which in turn leads to further iterations of design. The whole process to complete a design varies in the number of iterations—it can be excessive or light, depending on the team and client.

However, I’ve recently discovered several advantages to collaborative interaction design—that is, working alongside another designer on the same project. Collaborative design can reduce the number of iterations it takes to reach a high quality of design.

Add Comment

Employee Spotlight: Jim Adams

cassie.mcdaniel@ldschurch.org (Cassie McDaniel) — Thu, 09 Jul 2009 19:45:44 +0000

Question

What do you do at the Church?

Answer

As a member of the Information and Communications Systems department (ICS) Mobile Device Team, I help coordinate cellular communications for Church headquarters. That includes ordering cell phones and mobile broadband data cards for laptops, helping employees with an array of phone issues, and generally safeguarding the Church’s investment in this popular business tool.

Question

What role do you think the Mobile Device Team plays in the Church organization?

Answer

We try to make the employees’ mobile device experience as smooth and trouble-free as possible. For example, a lost, damaged, or stolen cell phone can represent a minor tragedy in the life of a citizen of the 21st century! We resolve problems as painlessly as possible by having a small stock of lightly-used surplus devices available for immediate replacement. This minimizes “phoneless” down-time. Without this service, hundreds of dollars would be spent on each replacement phone, so we feel we save the Church significant dollars as we help maximize employee productivity.

Add Comment

Invitation to Participate in Meetinghouse Webcast 2.0 Software Beta Test

cassie.mcdaniel@ldschurch.org (Jacob Stark) — Thu, 02 Jul 2009 21:12:12 +0000

The Information & Communication Systems department of The Church of Jesus Christ of Latter-day Saints wishes to invite local Church units familiar with webcasting to participate in the beta test of Meetinghouse Webcast 2.0 software. Webcast technology provides an alternative to travel for stake conferences, regional conferences, firesides, and training meetings by allowing local units of the Church to webcast these meetings over the internet to other locations.

Add Comment

Participate in Community Development

cassie.mcdaniel@ldschurch.org (Nathan Dickamore) — Tue, 30 Jun 2009 16:37:18 +0000

I recently attended a keynote presentation given by Michael Tiemann, Red Hat’s Vice President of Open Source Affairs (listen to Michael Tiemann’s presentation here). Michael's talk focuses on "exonovation" (a word he made up), or innovation from an open community, and how it can make a product even better than a closed, controlled, proprietary effort. Exonovation involves creating a more open, positive, and productive environment, leveraging the innovation of people external to your organization and is a common practice used in the open source development community.

Listening to this presentation as a software engineer for the LDS Church, I could see how exonovation and the community could really benefit the work here at the Church. We have found that as an organization we have many software dependencies, yet we do not have the funds or resources necessary to meet all of these dependencies. Exonovation provides a way for us to extend our resource cap to a possibly unlimited amount.

Add Comment

Mormon Channel iPhone App Now Available

cassie.mcdaniel@ldschurch.org (Cassie McDaniel) — Thu, 25 Jun 2009 21:44:34 +0000

The Mormon Channel iPhone App is now available for free in the iTunes store. This is the first LDSTech community collaboration project to be released.

Community collaboration is ongoing at the LDSTech Wiki. The purpose of the wiki is for Church employees and community members to collaborate on various documents and technology projects sponsored by the Church. We invite all to participate. New users, please review the Requirements for Participation and wiki Guidelines pages.

We can still improve the Mormon Channel iPhone Application. There is immediate need for quality assurance to find and fix bugs. You can suggest new features and report bugs in Jira.

To learn more about helping out with community collaboration projects on the LDSTech wiki, read about getting started.

Add Comment

Finding Creative Inspiration from the Creation

cassie.mcdaniel@ldschurch.org (Richard Moore) — Tue, 23 Jun 2009 19:49:27 +0000

Looking to the work of the Master can help enhance our own creativity.

Everything Was Created Spiritually Before It Was Created Physically

And I, the Lord God, formed man from the dust of the ground, and breathed into his nostrils the breath of life; and man became a living soul, the first flesh upon the earth, the first man also; nevertheless, all things were before created; but spiritually were they created and made according to my word. (Moses 3:7)

There are many scriptural sources of the initial spiritual creation of all things. The importance of a plan is apparent in this fact. Nothing was thrown together haphazardly. Every blade of grass, every insect, every tree and flower, and every one of us were fully realized first in spirit and then in flesh.

In our own creative works, taking the time to plan allows us to test ideas, work out the kinks, and define the best solution before we begin the actual creation. We save time, energy, and money—and end up with a better product. Planning allows us to make mistakes without fear and to refine the best ideas while letting the weak ones fade away.

Add Comment

Working in a Small Church IT Shop

cassie.mcdaniel@ldschurch.org (Hyrum Haynes) — Fri, 19 Jun 2009 00:28:51 +0000

When someone thinks of IT and the Church, they probably think of the large, complex environment at the Church’s downtown SLC campus, with a staff of dedicated IT professionals in many different specialties. Or perhaps they would think of the more modest technical needs of local units, area and mission offices, seminaries and institutes, MTCs, or temples. Indeed, the Church has technical needs wherever it has a presence. Those needs vary according to the function and size of the particular location.

I am privileged to have worked at LDS Philanthropies (formerly LDS Foundation) for the last 18 years, first as a Technical Service Representative (TSR) and now as a software engineer. I have seen this department grow in size and change in technology. LDS Philanthropies (LDSP) is a department of the Office of the Presiding Bishopric and is responsible for philanthropic donations to the Church and its affiliated charities, including the Church’s educational institutions. We maintain the donor records for these charities, as well as the alumni databases (but not educational records) of BYU, BYU-Idaho, BYU-Hawaii, and LDS Business College. The database resides on an IBM System i (AS/400) located in the BYU Data Center. The AS/400, along with the Ascend database, was chosen in 1990 because it was the best system then available to support the needs of LDS Foundation.

Add Comment

Test Automation

cassie.mcdaniel@ldschurch.org (Brandon Nicholls) — Tue, 16 Jun 2009 21:32:50 +0000

When I was a kid, I watched a cartoon called The Jetsons. The futuristic family had a robotic maid named Rosie who took care of the household chores. To make things interesting, she was given a personality, and occasionally she demonstrated emotions. After watching this show, I would think about the future and imagine robots doing the majority of our work for us while we sat back and did more important things. Although many of these imaginings have not materialized, I often think of this when I am writing test automation as a QA engineer for the Church.

Even a simple application can have a large number of test cases that need to be verified. Let’s pretend we have an application with 100 test cases. The sooner we realize a given test case is failing, the better off we will be. Accordingly, we would want to test after each successful build. Let’s suppose that ten new builds are created each day. If we tested all of this functionality with each new build, we would be testing 1,000 (100 X 10) cases day in and day out. Umm . . . I think we need a Rosie!

Add Comment

The Cost of Bugs

cassie.mcdaniel@ldschurch.org (Christian Hargraves) — Thu, 11 Jun 2009 15:58:52 +0000

Two things contribute to unhappy customers: bugs and late delivery. A bug is generally referred to as a feature in the application that does not work according to the customer’s expectations. This can be due to an unspecified or misunderstood requirement or just a mistake in the development of the software. Either way, bugs not only frustrate the customer, they considerably expand the project’s cost and timeline.

Making an effort to catch bugs at the earliest point in the life cycle will result in a higher return on investment (ROI). The cost of fixing a bug differs depending on the stage of development it is caught in.

Requirements Stage: Bugs caught in the requirements writing stage simply cost the time to rewrite the requirement. Time spent in this stage is usually constant.

Coding Stage: Bugs caught here require developer hours. Time varies but is considerably less than fixing a bug found by someone else. When a bug is found during this stage, the developer discovers it, already understands the problem, and often knows how to fix it.

Integration Stage: Bugs caught here require developer and other system engineer hours. Time is usually at least twice as much, since the problem occurs at a higher level and there is a need to figure out which exact code or configuration is wrong.

Testing Stage: Bugs caught here require developer, system engineer, PM, and QA hours. The process is much larger than before. Now things need to be tracked and prioritized. This now requires finding reproduction steps, submitting a bug, prioritizing the bug, meeting with developers, fixing the bug, pushing the fix to the test environment, verifying the fix, and tracking the changes of the bug in the system.

Production Stage: Bugs caught here require developer, support, system engineer, PM, customer, and QA hours. This process always involves all of the roles. It requires more planning and more prioritizing than in the testing stage. Usually a phone call comes to support, and they decide if it's a bug or if it’s working as designed. The customer is notified, the PM is contacted, and then the process in the testing stage is followed.

Add Comment

Working with Names from Around the World

cassie.mcdaniel@ldschurch.org (Cindy Conlin) — Tue, 09 Jun 2009 15:50:06 +0000

One of the first steps in building global software is to recognize that many assumptions Americans often hold about how people’s names work are not universally true. Much of the software used by the Church use people’s names, and we’ve found an amazing amount of diversity in the name-related traditions of different cultures. Can you distinguish fact from fiction in the name myths?

Myth 1:

The concepts “first name” and “last name” are consistent across cultures.

False. In America, we use the Western name order, and so Americans instinctively know that the last name in George Timothy Clooney is also the family name. By contrast, several other cultures place names in the Eastern order, always listing the family name first. For example, the Chinese will always use Jacki Chan’s Chinese name in the order “Chan Kong Sang”, and they know that the first name “Chan” is the family name.

As a result, if you label name fields in your global software with the position-based terms FirstName and LastName, you may not get what you expect.

Add Comment