Introduction to the Tcl Language

The next five chapters constitute a Tcl language tutorial. This chapter provides an overview of the Tcl syntax, data structures, and enough commands to develop applications. Chapter 4 discusses Tcl I/O support for files, pipes, and sockets. Chapters 5–8 introduce more commands and techniques and provide examples showing how Tcl data constructs can be used to create complex data constructs such as structures and trees. Chapters 9 and 10 introduce the TclOO object-oriented support package and explain some tricks in using dynamic and introspective object-oriented programming effectively.

This introduction to the Tcl language will give you an overview of how to use Tcl, rather than be a complete listing of all commands and all options. The on-line reference pages are the complete reference for the commands. See Chapter 1 for a discussion on how to access the on-line help on UNIX, Macintosh, and Windows platforms. The companion website contains a Tcl/Tk reference guide that contains brief listings of all commands and all options.

If you prefer a more extensive tutorial, see the tutorials list on the companion website. You will find a copy of TclTutor, a computer-assisted instruction program that covers all of the commands in Tcl, and most of the command options.

Chapters 11 through 14 constitute the Tk tutorial. If you are performing graphics programming, you may be tempted to skip ahead to those chapters and just read about the GUIs. Don’t do it! Tcl is the glue that holds the graphic widgets together. Tk and the other Tcl extensions build on the Tcl foundation. If you glance ahead for the Tk tutorial, plan on coming back to fill in the gaps.

This book will print the command syntax using the font conventions used by the Tcl on-line manual and help pages. This convention is as follows.

commandname   – The command name appears first in this type font.
subcommandname   –  If the command supports subcommands, they will also be in this type font.
-option    -  Options appear in italics. The first character is a dash (-).
argument   - Arguments to a command appear in italics.
?-option?    – Options that are not required are bounded by question marks.
?argument?   -  Arguments that are not required are bounded by question marks.

The following is an example.
Syntax: puts ?-nonewline? ?channel? outputString

The command name is puts. The puts command will accept the options -nonewline and channel as arguments, and must include an outputString argument.

 

Read more

Users and purposes of study plans

Research plans serve several purposes. The first is providing a blueprint for the planned research activity. Plans help set a common language between all involved parties, and they are a tool for reassuring stakeholders that what was agreed upon during initial conversations is in fact what is going to happen.

When you suspect that people are too busy to read research plans, I suggest you schedule a meeting with a goal to make immediate stakeholders aware of the study plan and to gather their feedback. In some cases, you will need them to sign off on a plan to make sure that you are covered in case they change their minds (I must admit that I’ve never done this, but I am aware of such situations). In any case, use this opportunity to involve everyone in setting the plan for the study. Carefully listen to criticism and ideas different than yours to learn more about what stakeholders expect to get from the study.

Keep in mind that different stakeholders might be interested in different aspects of a research plan:

■ Product managers and software developers will mostly be interested in the goal, research questions, and schedule. In some cases, they will also be interested in participant criteria, but not always. These stakeholders are usually interested in goals and questions because these determine the content of the study and its focus. They will also be interested in the schedule to make sure that it meets their needs for making timely design, business, and development decisions. Participant criteria will interest them if they are targeting a very specific audience and they want to make sure that study participants are representing this audience as much as possible.

■ Designers are your closest allies. They will probably show interest in the entire plan because they are probably the stakeholders who are most affected by the results of the study. They are the ones who probably need to create something or make changes based on the results.

■ Salespeople will be interested in participant criteria because this will affect their level of involvement in the process of recruiting participants for the study.

■ Executives will probably be interested in the study goal and in the overall cost of the study, as they are likely sponsoring the study. Usually, their bandwidth does not allow them more than that.

■ Other UX researchers internal and external to your organization might be interested in your plan for two good reasons. First, they might be coleading a study with you. It is critical that all leaders be on the same page at the start of the study. For instance, a study with coleaders in different countries is vulnerable to chaos and lost time if the goal is not stated precisely and checked to see that the translation hasn’t changed the meaning. Second, other researchers might want to learn from you. Many plans that I read help me shape better plans for my own studies.

■ You! The plan is mostly for you. As soon as you put your thoughts in writing, something happens, and you find holes in them. These holes you find help you improve your plan. A written plan also helps you focus and better prepare for the study. The fact of the matter is that if you can’t boil your plan down to a single page, it means that you yourself probably don’t really understand it.

One thing you might ask yourself is when the best time is to share a plan with stakeholders. I’d say early and often. Share a plan when you have only draft goals and research questions. Share it when you have a final list of goals and questions. Share it again when you’ve selected a methodology. You see where I’m going with this. It’s a bad sign when your stakeholders are surprised by the content of a study plan.

 

Read more

Introduction

 

Human beings have been part of social networks since our earliest days. We are born and live in a world of connections. People connect with others through social networks formed by kinship, language, trade, exchange, conflict, citation, and collaboration. Computer technologies used to create social networks are relatively new, but networks of social interactions and exchanges are primordial. Simply stated, a network is a collection of things and their relationships to one another. The “things” that are connected are called nodes, vertices, entities, and in some contexts people. The connections between the vertices are called edges, ties, and links. Many natural and artificial systems form networks, which exist in systems from the atomic level to the planetary level. Social networks are created whenever people interact, directly or indirectly, with other people, institutions, and artifacts. Social network theory and analysis is a relatively recent set of ideas and methods largely developed over the past 80 years. It builds on and uses concepts from the mathematics of graph theory, which has a longer history. Using network analysis, you can visualize complex sets of relationships as maps (i.e., graphs or sociograms) of connected symbols and calculate precise measures of the size, shape, and density of the network as a whole and the positions of each element within it. 

 

 

 

 

 

 

 

Read more

Chapter 3: CULTURE AND UX

How many cross-cultural slips and gaps does that small anecdote hold? Attitudes toward time, expectations about appropriate activities, communication style, just to name a few. Aaron Marcus told us that story to illustrate the sort of cultural differences that cause heartaches, conflicts, and misunderstandings all the time. What is acceptable in one culture can be unthinkable in another.
We talk about “cross-cultural design” or “bridging cultures” – what does that mean for UX? User experience is based on understanding users. And users can now seem more diverse than ever. The UX challenges for this new, connected world are based on its biggest benefit: we are more connected.

This chapter looks at questions about culture and what it
means for UX:
• What do we need to know about cultures to do good UX?
• Are differences or similarities between cultures more important
for UX design?
• Are there models that will help us understand culture and
apply it in our UX work?
• How much does language matter in design and other UX work?

Read more

SERVICE INTEGRATION IN THE DATA CENTER

The SOI of the enterprise DC cannot do without important network services such as firewall capabilities
and server load balancing. The services aggregation layer is a good place to integrate firewalls and
SLBs because it is typically the demarcation between L2 and L3 in the DC, and it allows these intelligent
service devices to be shared across multiple switches in the access layer. There are two ways to
integrate firewalls and SLBs:

• The use of separate services aggregation–layer switches as external services chassis to house
firewall and SLB service modules.
• The use of standalone appliance devices.
This book covers only the services chassis approach for housing firewalls and SLBs.

Read more