An Object Oriented Collaboration Flow Management System for Virtual Team Support
Jacques Lonchamp
LORIA, BP 239, 54506 Vand?uvre lès Nancy Cedex, France
jloncham@loria.fr
Abstract. Collaboration flow management is a new paradigm for virtual team
support which aims at assisting the opportunistic flow of collaboration within a
distributed project, considered as a living and self-organizing system. Such a
flow includes informal and formal, synchronous and asynchronous, task-
oriented and project management-oriented collaborative sessions. Some of them
are elements of model-driven issue-based process fragments. The paper defines
the collaboration flow management paradigm and describes our Java prototype
of collaboration flow management system through a realistic scenario. The pa-
per also discusses how a high level of flexibility is obtained through a set of de-
sign choices and object oriented implementation techniques.
1 Introduction
A virtual team (VT) is a team, i.e. a group of people who work interdependently with a shared goal, distributed across space, time, and organization boundaries, and linked by webs of interactive technology. VTs can improve work performance by reducing costs (cutting travel costs and time), shortening cycle time (moving from serial to parallel processes), increasing innovation (permitting more diverse participation, and stimulating creativity), and leveraging learning (gaining wider access to expertise, and sharing best practices). The success of a VT approach depends on a set of psychologi-cal, organizational, and cognitive factors [10]. A computerized support for VTs should take into account these factors and include them in its basic requirements. First, a sense of identity and membership is necessary for VTs. Periodically performing informal virtual meetings is not sufficient for developing a collaborative attitude. Participants must feel that the supporting environment help them to do important and constructive things together, in synergy. Secondly, traditional authority is minimized in VTs, which develop an inner authority based on competencies. In VTs, power comes from information, expertise, and knowledge, not from position. The important things done together through the supporting environment should include expression of competencies, externalization of knowledge and mental models related to the task in hand. Third, trust is the key to VTs. People work together because they trust one an-other. People make deals, set goals, and lend one another resources. Trust can build with the recognition of the contribution that everyone makes, the clarity of positions and commitments. Finally, project and process management is a critical ingredient for
successful distributed work. Co-located teams can quickly clarify goals, correct mis-understandings, and work through problems. VTs need to be more explicit in their planning and their processes. When considering these requirements, we claim that no existing paradigm for cooperative systems, neither the workflow management para-digm nor the workgroup computing paradigm, is satisfying. A new paradigm is re-quired for VT support. The next section elaborates this idea and defines such a para-digm, called the ‘collaboration flow management paradigm’. Section three describes our current Java prototype of collaboration flow management system through a realis-tic scenario. Section four discusses how a high level of flexibility is obtained through a set of design choices and object oriented implementation techniques. Finally, the last section compares our proposal with related work and draws some perspectives.
2 The Collaboration Flow Management Paradigm
2.1. Motivations
The first section stresses the importance of supporting the VT life cycle process. VT projects usually follow a life cycle with an alternation of divergence phases, during which people work individually, and collaborative convergence phases, during which people build some shared understanding, discuss for discovering and solving the divergences accumulated during individual work, and drive the project. A classical Workflow Management System (WfMS) provides support for coordinating individual activities, as those occurring during divergence phases. Generally, a WfMS provides no support for collaborative activities. Conversely, a VT environment should mainly support convergence phases. The ‘workgroup computing paradigm’ is not a satisfying solution because it considers collaborative tasks in isolation and does not support the life cycle process as a whole. A computerized environment for VTs should support-processes whose steps are collaborative sessions either synchronous or asynchronous, informal or formal. Following the requirements of the first section, we analyze these sessions as working sessions, during which participants express their views, compe-tencies, positions, and commitments about the task in hand. At a very abstract level, we feel that issue resolution is the basic building block which can be used for describ-ing all these activities. Participants discuss and solve many issues about the artifacts, the shared context, and the collaboration process itself. The environment should sup-port the definition and management of processes whose steps are issue-based syn-chronous or asynchronous, informal or formal, collaborative sessions.
Otherwise, a VT is a living and self-organizing system. As Peter and Trudy John-son-Lenz explain [6], ‘post-mechanistic groupware’, like all living systems, are ‘rhythmic’ and made of ‘containers’ with flexible and permeable ‘boundaries’. The VT computerized environment should support in particular a range of session types (containers types) providing different ‘collaboration rhythms’, in accordance with the task urgency and the required depth of issue analysis, and different ‘group bounda-ries’, through the evolving definition of a ‘core team’ and an ‘extended team’. Proce-
dures (process models), context, and timing are the three other primitives of post-mechanistic groupware [6]. The choice between these forms (containers, rhythms, boundaries, procedures) should be made dynamically and collectively during the course of the project.
2.2. Basic Functionalities of a Collaboration Flow Management System
From above, the following four basic functionalities are identified:
(1) Support different types of short/rapid, more or less formal, synchronous sessions for the core team, such as artifact-centered informal sessions (around a shared docu-ment or a free hand drawing) or formal argumentation sessions (with different rhythms and styles of interaction: ‘free’, ‘turn talking’, ‘circle’, ‘moderated’, …). Composite synchronous sessions can mix formal and informal times.
(2) Support longer/slower/deeper, formal, asynchronous sessions for the core team, controlled through the enactment of issue-based and session-based collaborative process model fragments. Such model fragments specify for instance various brain-storming processes, document review or inspection processes, knowledge elicitation processes, solution evaluation processes. When needed, an asynchronous issue-based session within a process fragment can be transformed into a synchronous session for continuing with a faster rhythm the resolution of conflicting issues (see Fig.1). Proc-ess model fragments can be built, refined, or changed dynamically, at run time. (3) Support the overall collaboration flow: some initial asynchronous Project Man-agement (PM) process enables project initiators to launch the synchronous sessions and the asynchronous process fragments (see Fig.1). This initial PM process is the spring of the opportunistic flow of collaboration that the VT generates, which can include in particular other PM processes better suited to the circumstances and which replace the initial one (see section 3.3).
(4) Play the role of a project memory, storing all project related information: arti-facts, debates, free hand drawings, messages, process trace, etc. These elements can be externalized, for instance as HTML/XML documents, for easier access and feedback from the extended team during asynchronous informal sessions on the Web.
3. A Prototype of Collaboration Flow Management System
In this section, we describe a scenario supported by our prototype of object oriented Collaboration flow Management System (CfMS). Our lab plans an extension of its building. A VT has been created for discussing different aspects of the project. The team includes representatives of lab members and participants coming from the uni-versity, the town, and the firm of architects. A kick-off informal orientation meeting has first planned a set of virtual meetings about specific questions. These synchronous sessions are organized through the asynchronous PM process (see section 3.3).
3.1. Synchronous Session Support
The session described here is about car parking near the lab. Such a synchronous session does not follow any predefined execution path: the session moderator can describe the problem and organize the work by using the audio channel.
In our scenario, the problem is first informally discussed through textual or graphi-cal annotations on the overall building plan (see Fig.2). Social protocols, such as au-thor identification with colors, can be negotiated. Clarifications may be obtained through the chat tool. In a second time, each emerging controversial issue can be for-mally discussed with explicit arguments and a ‘turn talking’ policy (‘free’ and ‘moder-ated’ policies are also available). On the basis of the resulting argumentation trees (similar to those produced during asynchronous sessions which are described in more details in section 3.2.2), the moderator can select some solutions and measure the consensus within the core team with the voting tool. All documents (annotated plans, argumentation trees, vote results) can be saved as HTML documents for feedback from other lab members.
Fig. 2. The synchronous session support, with a formal argumentation (1), a vote result (2), an informal discussion (3) about the freely annotated architectural plan of the lab (4).
3.2. Model-driven Collaborative Process Fragment Support
Later in the course of the project, the VT has planned an asynchronous model-driven process fragment for a systematic study of the existing cafeteria dysfunctions and for proposing a consensual list of possible causes and solutions for the new cafeteria.
3.2.1. The Meta Model
The process modeling language is defined by a meta model, which extends the classi-cal process view and organizational view of WfMSs with a decision view and a
Fig. 3. The basic elements of the meta model
The process view mainly includes ProcessFragment and Session types. Each process fragment instance is structured into a network of session instances (also called ‘phases’), with precedence relationships, and special phase instances corresponding to the classical workflow operators (AND split, OR split, AND join, OR join phase types). The knowledge view mainly includes Artifact, Component, and Application-Tool types. Artifact types specialize generic types such as Text, List, Table, Graph (concept map), or Image. Component types specialize generic types such as ListEle-ment, GraphNode, or GraphEdge. ApplicationTool types mirror the specialization of artifact types, with specializations of generic types such as TextViewer, ListViewer, TableViewer, or GraphViewer. Each Session type grants access to some Application-Tool types. The organizational view mainly includes Role and Actor types. The deci-sion view describes collaborative work at a fine grain level. Each Session type is de-fined internally by a set of Issue types, which must be solved either individually or collectively. Each Issue type is characterized by a set of Option types, which describe the possible solutions. At run time, one option is chosen trough an argumentation process. Each Option type can trigger, when it is chosen, some Operation type, which
can change some Component, or change the process state (e.g. termination of a Ses-sion), or change the process definition itself. This meta model is implemented as an object oriented class model. Core classes implement the basic environment mecha-nisms (enactment, awareness, ...). Application specific classes specialize core classes and are generated by compiling a process fragment model description. Instantiation of specialized classes takes place statically for instances which are necessary for starting the process or dynamically at run time. All instances are persistent.
3.2.2. The Scenario
A process model fragment is selected and instantiated (see section 3.3). The fragment implements the DIPA approach [9] which formalizes collaborative problem solving for synthesis situations (design of solutions), and for analysis situations (diagnosis). A typical DIPA-based analysis process includes three steps: in the first one, the problem is described and data (‘symptoms’) are collected; in the second one, data are used to find interpretations, i.e. possible causes; in the last one, interpretations are used to devise solutions that serve as reparations suppressing the causes of the symptoms. The process model fragment includes three session types. The ProblemDefinition session type contains three issues types for defining the problem (individual issue available to the session manager), proposing a symptom (individual issue available to all partici-pants), and terminating the phase (collective issue). The ProblemAnalysis session type contains five issue types for proposing a cause (individual issue available to all par-ticipants), linking a cause to a symptom (individual issue available to all participants), challenging a cause (collective issue for either keeping or discarding the cause), pro-posing new symptoms (like in the first phase), and terminating the phase (collective issue). The ProblemResolution session type contains four issue types for proposing a solution (individual issue available to all participants), linking a solution to a cause (individual issue available to all participants), challenging a solution (collective issue for either keeping or discarding the solution), and terminating the phase (collective issue). The instantiated process is a sequence with one phase of each type.
When a user, say Jack, logs in a process fragment where he plays a role, he can use the What can I do? guidance query and the Whats’new? awareness query (for knowing elements that have changed since his last logout). He can also browse various textual and graphical representations of the model types and the process instances. All par-ticipants only act by solving typed issue instances. If Jack wants to propose a new cause, he raises an individual ProposeCauseIssue. Then he has to explain his intention as an argument. This individual issue is automatically solved and triggers an operation which creates a new Cause component. If Jack wants to challenge a cause given by Peter, he raises a collective ChallengeCauseIssue. Then, he gives an argument in favor of the Discard option. Other participants can react (e.g. support the Keep option or challenge Jack’s argument). The debate takes the form of an argumentation tree, pos-sibly with qualitative importance constraints between arguments. Such a constraint (more/less/equally important than) opens a sub issue, called a ‘constraint issue’, for debating about the value of the constraint. Participants can access various representa-tions of argumentations, as a threaded discussion form (Fig.3) or a graphical form with a ‘playback’ facility (Fig.5). At each argumentation move, the system computes a preferred option by using an argumentative reasoning technique close to the approach
proposed in Zeno [4]. The system provides also statistical charts about the participa-tion, the favorite option of each participant, and the level of conflict, based on the number of changes of the global preferred option. Suzan, who plays a role giving the capability to solve this type of issue, terminates the debate by choosing one option. The issue resolution triggers an operation that either keep or discard the challenged cause. Different tools, like table or graph viewers, are available to the session partici-pants for accessing the process artifacts, such as the symptom/cause/solution concept graph of Fig 5.
Fig. 4. The asynchronous process-centered support, with a graphical view of an issue (1), the DISA concept graph built during the session (2), the action panel (3) with a ‘What Can I do?’ guidance query (4), the notification panel (5), the statistical analysis of the debate (6).
3.3 The Project Management Process
In our scenario, the initial PM process follows a very simple model: participants play-ing the role of ProjectManager can plan synchronous sessions and asynchronous proc-ess fragments by solving CreateSessionOrProcess individual issue instances. Each resolution adds a new description (name, date, objective, participants, status, results, ...) to a ProjectPlan artifact and calls people for participation through email genera-tion. This planning activity can also result from synchronous orientation meetings with the core team. The ProjectManager can also publish in a ProjectRepository artifact, HTML documents produced by the terminated processes/sessions (PublishResult issue type). A dedicated tool for accessing them is generated and appears in the tool list of the PM session (see Fig.6). The ‘What’s new?’ awareness query at the level of the PM process can help to coordinate concurrent process fragments: for instance, when a first one (pf1) publishes a new result, a second one (pf2) can start a phase taking the new document into account (see Fig.6). This mechanisms also work for individual activi-ties which are out of the control of the CfMS.
(1)
(2)
(3)
(4) (5)
(6)
Fig. 5. The asynchronous project session support with the project plan (1) and the project repository (2). A dedicated tool is generated for each published result (3).
Fig. 6. Synchronization of process fragments.
4. Flexibility of the CfMS Prototype
Flexibility is a central requirement for CfMSs. We briefly emphasizes nine points which contribute to the flexibility of our prototype.
(1) The overall design enables switching between informal and formal support . For instance, during a synchronous session, an informal debate around a document can switch to formal argumentations. A collaborative problem solving session can either be organized as an informal meeting or as a formal model-driven asynchronous ses-sion. At the end of such a formal process among the core team, the produced artifacts can be proposed to an extended team for informal discussion on the Web.
(2) The overall design also enables switching between asynchronous and synchro-nous work. An issue resolution can start asynchronously and terminate synchronously or the opposite.
pf1 PM process launch
pf2 publish read ProjectRepository (1)
(2)
awareness
(3) The concept of process model fragment is important for ensuring the fluidity of the global process. There is no rigid overall process model and each fragment allows to redefine many organizational parameters contributing to the global fluidity: fluidity of the core team and extended team boundaries, fluidity of the roles and the assign-ment of the actors, fluidity in the definition and organization of the sessions, fluidity in the rhythms between different styles of interaction, etc.
(4) A process fragment is a data object not a program or a script. The information about the process state and the process evolution is distributed over the process ele-ments. This object orientation allows a process fragment to be modified during its enactment for exception handling or opportunistic adaptation to new situations. How-ever, we favor as far as possible disciplined predefined changes (see point 5).
(5) A model fragment can include open points for refining the model at run time. In our model an open point takes the form of an instance of a model refinement phase type which includes a model refinement issue type, with one option type for each pos-sible refinement. At run time, one of these options is chosen, either individually by the project manager, or collectively by the core team. The corresponding refinement is deployed, by instantiating new phase instances and new phase precedence relation-ships. By this way, artifact production and process refinement are performed similarly. For instance, such a refinement phase at the end of PM model fragments can enable the project manager (or the core team) to change the PM policy. In our scenario, a richer PM model could include an issue type for publicizing individual tasks by pub-lishing them in the ProjectPlan. Participants could commit themselves to do a given task, and their commitments could be published in the ProjectPlan.
(6) The implementation makes easy run time evolutions of the process fragments. In
a model each specific type is the specialization of one of the generic types of Fig.3. Relationships at the type level (e.g. the ProblemAnalysis session type contains the ProposeCause issue type) are expressed and stored persistently as relationships be-tween instances of “meta classes” which are associated to all model classes (see Fig.7).
generic
classes
specific
classes
instances
instances the meta class instance
Fig. 7. The implementation organization
Thus, many process model structural changes between existing components are per-formed dynamically through predefined ‘meta issue’ types (e.g. AddIssueTypeTo-PhaseType) in the same way as changing process instances. It is worth noting that,
unlike many other systems the ‘meta interface’ of our system (i.e. the set of the ‘meta issues’) is a collaborative interface.
(7) For creating new model classes (and the corresponding meta classes) we use the ‘linguistic reflection’ technique [8]. Predefined meta issues generate new classes in the form of Java code, compile, and instantiate them dynamically. This technique is effective when the code can be generated on the basis of a few number of parameters provided by end users at run time. It is quite frequent, because specific classes are specializations of the predefined core classes and most elements are inherited from the super classes. For instance, creating new role types is easy, because no specific code is necessary: all the semantics of the role type is expressed in terms of relationships at the class level (see the Can Raise, Can Participate, Can Solve, Can Launch relation-ships of Fig.3). In some other cases, such as creating new operation types, potentially complex code has to be created. The solution is to allow dynamic coding in the proc-ess model language followed by the whole transformation process (starting with our specific compiler producing Java code followed by the persistency pre processor, the regular Java compiler, and the instantiation process [13]). This approach is possible under the control of a single participant by calling the integrated development envi-ronment (editor, compiler, instantiation tool, verifier) from the PM process. We de-scribe in the next point another approach which allows the core team to participate to the model definition even if its members have no detailed knowledge of the process modeling language.
(8) In this approach, the general design of the model fragment is collaboratively de-fined either during an informal virtual meeting or by using a dedicated model frag-ment which guides the model elicitation process (definition of main phase, issue, and role types, and generation of the model skeleton). Then, on the basis of this rough design, a model developer can complete immediately the code and install/instantiate the new fragment with the development environment. Finally, it is possible to perform immediate tests with the core team and possibly iterative improvements before the actual execution (see Fig.8).
(9) The last aspect of flexibility is related to the idea of core services and substitut-able external services. In our vision, a CfMS should only provide the core services necessary to support collaboration. Even if the prototype provides low level services for exchanging files and managing a basic file/directory-based repository, in most cases, a document sharing system for distributed teams such as BSCW [1] or our Java Motu prototype [16] should complement the CfMS for managing (sharing, versioning) the shared application artifacts created during individual steps, such as the architec-tural plans in our scenario. By this way, collaboration is not tied to some particular
document management policy. Similarly, no integrated support is provided for coor-dinating the execution of individual tasks. A cooperative WfMS or ad-hoc WfMS could also complement our CfMS from this point of view.
In summary, all the evolution work (model refinement at open points, punctual changes with the meta interface, and on line model development) is performed through specific issue types (refinement issues, meta issues, model elicitation issues) and is similar to the application-oriented work and the project management work. 5. Related work and perspectives
Our approach is rooted in a wealth of research projects. Among the most important precursors, we can cite Conversation Builder [7] (for genericity, process model frag-ments, asynchronous collaboration), Cognoter/Argnoter [17] and gIBIS [3] (for argu-mentation and concept mapping). We can also emphasize, in many application do-mains, a trend from hard-coded tools to model-based generic environments. It is the case for instance for review/inspection systems, moving from specialized tools such as ICICLE, Scrutiny, etc. [15] to generic review/inspection environments such as CSRSv3 [18] or ASSIST [14].
More specifically, two recent systems have strong similarities with our proposal. We share with Compendium [2] the idea of modeling collaborative work through a set of issue types, called ‘question-based templates’ in Compendium. We share with SCOPE (‘Session-based Collaborative Process-centered Environment’)[5] the idea of ‘session based process modeling’. SCOPE roughly coincides with our definition of a CfMS. But SCOPE, on the one hand does not provide high level interaction services, such as our argumentation and decision-making services, and on the other hand im-poses some low level mechanisms, such as a specific concurrency control mechanism, that we exclude from our core services. At the commercial level, VT support systems are mainly collaborative portals such as Livelink virutalteams for instance [11] which provides six ‘walls’ (rooms) for six themes: people, purpose, links (between people and work), time, meetings, and content (documents). Such a portal does not provide a real process support and is not ‘proactive’ as our proposal.
For extending the core services of our CfMS prototype, future work will be di-rected towards a better support for the VT project memory by using XML technolo-gies. Such a memory should store and restore both in human-readable and machine-readable forms all kinds of information, such as the collaboration artifacts, the process history, the argumentation trees, and even the process model fragments themselves. Another important objective is to provide a larger library of reusable process model fragments, either task-oriented or PM-oriented, and to evaluate them through scenar-ios and experiments, such as those already performed with our previous prototype [13].
Acknowledgments
This work is part of the INRIA ECOO project. Bruno Denis and Fabrice Muller have contributed to the CfMS prototype development.
References
1. Bentley, R., Appelt, W., Busbash, U., Hinrichs, E., Kerr, D., Sikkel, K., Trevor, J., and
Woetzel, G.: Basic support for cooperative work on the World Wide Web. International Journal of Human-Computer Studies, 46 (1997)827-846
2. Conklin, J., Selvin, A., Buckingham Shum, S., Sierhuis M.: Facilitated Hypertext for Collec-
tive Sense making: 15 Years on from gIBIS. Tech. Report KMI-TR-112, Knowledge Media Institute (2001)
3. Conklin, J., Begeman, M.: gIBIS: A hypertext tool for exploratory policy discussion. ACM
Transaction on Office Information System, 6, 4 (1988) 303-331
4. Gordon, T.F., Karacapidilis, N.: The Zeno argumentation framework. Proc. 6th Int. Conf. on
AI and Law (ICAIL’97), Melbourne, Australia, ACM Press (1997) 10-18
5. Haake, J.M., Wang: W. Flexible support for business processes: extending cooperative hy-
permedia with process support. Information and Software Technology, 41, 6 (1999)
6. Johnson-Lenz, P., Johnson-Lenz, T.: Post mechanistic groupware primitives: rhythms,
boundaries and containers. Int. Journal Man-Machine Studies, 34 (1991) 395-417
7. Kaplan, S., Caroll, A.: Supporting collaborative processes with Conversation Builder. Com-
puter communications, 15, 8 (1992)
8 Kirby, G.N.C., Morrison, R., Stemple, D.W.: Linguistic reflection in Java. Software Practice
& Experience, 28, 10 (1998) 1045-1077
9. Lewkowicz, M., Zacklad, M.: MEMO-net, un collecticiel utilisant la méthode de résolution
de problème DIPA pour la capitalisation et la gestion des connaissances dans les projets de conception. Proc. IC'99, Palaiseau, France (1999) 119-128
I2CS 2001, Ilmenau, Germany, LNCS, Springer-Verlag (2001) 167-174
13. Lonchamp, J., Denis, B.: Fine-grained process modeling for collaborative work support:
experiences with CPCE. Journal of Decision Systems, 7 (1998) 263-282
14. Macdonald, F., Miller, J.: Automatic generic support for software inspection. Proc. 10th
International Quality Week, San Francisco (1997)
15. Macdonald, F., Miller, J., Brooks, A., Roper, M., Wood, M.: A review of tool support for
software inspection. Proc. 7th Int. Workshop on CASE (1995)
16. Motu system (available at https://www.doczj.com/doc/c0851901.html,/)
17. Stefik, M., Foster, G., Bobrow, D., Kahn, K., Lanning, S., Suchman, L.: Beyond the chalk-
board: computer support for collaboration and problem solving in meetings. CACM, 1, (1987) 32-47
18. Tjahjono, D.: Building software review systems using CSRS. Tech. Report ICS-TR-95-06,
University of Hawaii, Honolulu (1995)
北京泛源国际运输服务有限公司 美国各个州的缩写、全称、中文译名及首府 Alabama (AL) 亚拉巴马Montgomery蒙哥马利 Alaska (AK) 阿拉斯加Juneau朱诺 Arizona (AZ) 亚利桑那Phoenix菲尼克斯 Arkansas (AR) 阿肯色Little rock小石城 California (CA) 加利福尼亚Sacramento萨克拉门托Colorado (CO) 科罗拉多Denver丹佛 Connecticut (CT) 康涅狄格Harford哈特福德 District of columbia (DC) 哥伦比亚特区 Florida (GA) 佐治亚Atlanta亚特兰大 Hawaii (HI) 夏威夷Honolulu火奴鲁鲁 Idaho (ID) 爱达荷Boise博伊西 Illinois (IL) 伊利诺斯Spningfield斯普林菲尔德Indiana (IN) 印第安纳Indianapolis印第安纳波利斯Iowa (IA) 爱荷华Desmoines得梅因 Kansas (KS) 堪萨斯Topeka托皮卡 Kentucky (KY) 肯塔基Frankfort法半克福Louisiana (LA) 路易斯安那Baton Rouge巴吞鲁日Maine (ME) 缅因Augusta奥古斯塔 Maryland (MD) 马里兰Annapolis安那波利斯Massachusetts (MA) 马萨诸塞Boston波士顿 Michigan (MI) 密歇根Lansing兰辛 Minnesota (MN) 明尼苏达St.Paul圣保罗 Mississippi (MS) 密西西比Jackson杰克逊 Missouri (MO) 密苏里Jefferson City杰斐逊城Montana (MT) 蒙大拿Helena海伦娜 Nebraska (NE) 内布拉斯加Lincoln林肯 Nevada (NV) 内华达Carson city卡森城 New Hampshire (NH) 新罕布什尔Concord康科德 New jeresy (NJ) 新泽西Trenton特伦顿 New Mexico (NM) 新墨西哥Santa Fe圣菲 New York (NY) 纽约Albany奥尔巴尼 North Carolina (NC) 北卡罗来纳Raleigh罗利 North Dakota (ND) 北达利他Bismarck俾斯麦 Ohio (OH) 俄亥俄Columbus哥伦布Oklahoma (OK) 俄克拉何马Oklahoma City俄克拉何马城Oregon (OR) 俄勒冈Salem塞勒姆Pennsylvania (PA) 宾久法尼亚Harrisburg哈里斯堡 Rhode Island (RI) 罗得岛Providence普罗维登斯South Carolina (SC) 南卡罗来纳Columbia哥伦比亚 South Dakota (SD) 南达科他Pierre皮尔
F l a s h制作简单动画实 验报告 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
实验二秋水孤鹜的制作 一．实验目的 1.了解动画基本概念和原理。 2.了解Flash软件界面。 3.了解全部工具，掌握工具的使用。 4.熟练运用Flash制作简单动画。 二．实验要求 1.熟悉使用实验制作中所需要的实验工具，看视频完成作品制作 2.在完成作品的基础上，尽量让作品美观，自然 三、实验器材 1．实验所用计算机 2．Windows操作系统。 3．Flash软件。 4．实验示范视频 四. 1 新建一个Action 文件，将背景颜色改为#00ccff 2.打开颜色面板，笔触调为无色，选择线性渐变，左渐变颜色为#00276C，右渐变颜色为2EAAFC 如图： 3 最后单击矩形选择工具来绘制大海。 4.选择铅笔工具，在工具栏底部将铅笔模式设置为平滑。然后绘制云朵。绘制好云朵后使用颜料桶工具，选择线性渐变，左渐变为白色，右渐变为灰色。Alpha值为80% ，最后填充云朵颜色如图：
5.使用选择工具选择好云朵的轮廓线，然后删除。 6.选择渐变变形工具，单击云朵，对渐变色进行调整，然后选择修改—形状—柔滑填充边缘命令，修改参数如图这样就完成了一朵云彩。、依次对其他云朵做出修改。 7..使用刷子工具绘制飞鸟。选择刷子工具，在工具栏底部将笔刷形状变成矩形，颜色变成白色，然后开始绘制飞鸟。绘制过程中可以使用橡皮擦工具进行修改。 8.使用铅笔工具绘制芦苇叶。使用铅笔工具将笔触颜色改为灰色，将绘制好的芦苇叶用颜料桶工具填充，颜色为暗绿色然后进行按住alt进行复制，并做出调整。 9.最后使用钢笔工具绘制芦花。如图将芦苇花调整到合适的位置。 这样一个秋水孤鹜就完成了。
亚拉巴马州Alabama 缩写：AL 阿拉斯加州Alaska 缩写：AK 亚利桑那州Arizona 缩写：AZ 阿肯色州Arkansas 缩写：AR 加利福尼亚州California 缩写：CA 科罗拉多州Colorado 缩写：CO 哥伦比亚特区Columbia 缩写：DC 康涅狄格州Connecticut 缩写：CT 特拉华州Delaware 缩写：DE 佛罗里达州Florida 缩写：FL 佐治亚州Georgia 缩写：GA 夏威夷州Hawaii 缩写：HI 爱达荷州Idaho 缩写：ID 伊利诺伊州Illinois 缩写：IL 印弟安纳州Indiana 缩写：IN
爱荷华州Iowa 缩写：IA 堪萨斯州Kansas 缩写：KS 肯塔基州Kentucky 缩写：KY 路易斯安那州Louisiana 缩写：LA 缅因州Maine 缩写：ME 马里兰州Maryland 缩写：MD 马萨诸塞州Massachusetts 缩写：MA 密歇根州Michigan 缩写：MI 明尼苏达州Minnesota 缩写：MN 密西西比州Mississippi 缩写：MS 密苏里州Missouri 缩写：MO 蒙大拿州Montana 缩写：MT 内布拉斯加州Nebraska 缩写：NE 内华达州Nevada 缩写：NV
新罕布什尔州New Hampshire 缩写：NH 新泽西州New Jersey 缩写：NJ 新墨西哥州New Mexico 缩写：NM 纽约州New York 缩写：NY 北卡罗来纳州North Carolina 缩写：NC 北达科他州North Dakota 缩写：ND 俄亥俄州Ohio 缩写：OH 俄克拉荷马州Oklahoma 缩写：OK 俄勒冈州Oregon 缩写：OR 宾西法尼亚州Pennsyivania 缩写：PA 罗得岛州Rhode Island 缩写：RI 南卡罗来纳州South Carolina 缩写：
美国各州的缩写及主要城市 一、亚拉巴马州 英文州名(缩写)：Alabama (AL) 区号：205 – 251 – 256 – 334 主要城市： 1、伯明翰(Birmingham) 2、蒙哥马利(Montgomery) 3、亨次维尔(Huntsville) 4、土斯卡鲁沙(Tuscaloosa) 5、木比耳(Mobile) 二、阿拉斯加州 英文州名(缩写)：Alaska (AK) 区号：907 主要城市： 1、朱诺(Juneau) 2、安克拉奇(Anchorage) 3、费尔班克斯(Fairbanks) 三、亚利桑那州
英文州名(缩写)：Arizona (AZ) 区号：480 – 520 – 602 – 623 – 928 主要城市： 1、菲尼克斯[凤凰城](Phoenix) 2、吐桑(Tucson) 3、孟沙(Mesa) 四、阿肯色州 英文州名(缩写)：Arkansas (AR) 区号：501 – 870 主要城市： 1、小石城(Little Rock) 2、菲页维尔(Fayetteville) 五、加利福尼亚州 英文州名(缩写)：California (CA) 区号：209 – 213 – 310 – 323 – 408 – 415 – 510 – 530 – 559 – 562 – 619 – 626 – 650 –661 – 707 – 714 – 760 – 805 – 818 – 831 – 858 – 909 – 916 – 925 – 949 主要城市： 1、萨克拉门托(Sacramento) 2、索诺马(Sonoma) 3、圣荷西(San Jose) 4、洛杉矶(Los Angeles)
一、亚拉巴马州 英文州名(缩写)：Alabama (AL) 区号：205 – 251 – 256 – 334 主要城市： 1、伯明翰(Birmingham) 2、蒙哥马利(Montgomery) 3、亨次维尔(Huntsville) 4、土斯卡鲁沙(Tuscaloosa) 5、木比耳(Mobile) 二、阿拉斯加州 英文州名(缩写)：Alaska (AK) 区号：907 主要城市： 1、朱诺(Juneau) 2、安克拉奇(Anchorage) 3、费尔班克斯(Fairbanks) 三、亚利桑那州 英文州名(缩写)：Arizona (AZ) 区号：480 – 520 – 602 – 623 – 928主要城市：
1、菲尼克斯[凤凰城](Phoenix) 2、吐桑(Tucson) 3、孟沙(Mesa) 四、阿肯色州 英文州名(缩写)：Arkansas (AR) 区号：501 – 870 主要城市： 1、小石城(Little Rock) 2、菲页维尔(Fayetteville) 五、加利福尼亚州 英文州名(缩写)：California (CA) 区号：209 – 213 – 310 – 323 – 408 – 415 – 510 – 530 – 559 – 562 – 619 – 626 – 650 –661 – 707 – 714 – 760 – 805 – 818 – 831 – 858 – 909 – 916 – 925 – 949 主要城市： 1、萨克拉门托(Sacramento) 2、索诺马(Sonoma) 3、圣荷西(San Jose) 4、洛杉矶(Los Angeles) 5、圣地亚哥(San Diego) 6、旧金山(San Francisco)
第2单元动画制作好帮手——Flash 制作一个简单的动画 【教学内容】制作简单的“礼花”动画 【教学目标】 1、掌握创建、保存、打开Flash文件的方法。 2、学会制作简单的“礼花”动画。 【教学重点】 1、掌握启动和退出Flash软件的方法。 2、制作简单的“礼花”动画。 3、掌握新建、打开、保存Flash文件的方法。 【教学难点】 1、理解“文档”属性面板中各项参数的含义，会合理地设置文档属性。 2、制作“礼花”动画。 【教学课型】 新授课实践课 【教学准备】 Flash软件、教学光盘资源及教学课件 【教学过程】 一、复习引入 师：上一节课我们熟悉了一下Flash制作软件，我们来回顾一下Flash制作软件的各个表框。（1分钟）
那么这一节课咱们一起来了解一下Flash制作软件有什么作用（GIF格式图片展示）让同学们了解Flash制作软件是将静态的图片拼接制成动态的图片 所以今天我们一起来制作一个简单的动画（标题书写） 同学们，大家喜不喜欢烟花？ 想不想亲手制作一朵璀璨的烟花呢？ 那么下面我们一起来观看一下烟花视频，在看的同时，带着老师的几个问题去记录并思考： 1.视频里的烟花都有哪些颜色，哪些形状？2.你喜欢哪些形状和哪些颜色的烟花？ （播放：礼花绽放的动画）（（3分钟） 下面就请同学们来回答一下我刚才提出的三个问题：1.烟花有哪些颜色？ 请同学回答 2.烟花有哪些形状？ 请同学回答 2.你喜欢哪些形状和哪些颜色的烟花？ 请同学来回答 总结：综合同学们列举的烟花的形状，老师把他们归类成以下几种大类：数字、中英文、动物、植物、花果蔬菜等各种你所能看到的图形图案。 通过以上同学们的大胆创想以及根据老师在黑板上放置的这些图片，大家有没有迫不及待地想亲手制作一朵烟花视频呢？
亚拉巴马州Alabama 缩写：AL 宾西法尼亚州Pennsyivania 缩写：PA 阿拉斯加州Alaska 缩写：AK 罗得岛州Rhode Island 缩写：RI 亚利桑那州Arizona 缩写：AZ 南卡罗来纳州South Carolina 缩写：SC 阿肯色州Arkansas 缩写：AR 南达科他州South Dakota 缩写：SD 加利福尼亚州California 缩写：CA 田纳西州Tennessee 缩写：TN? 科罗拉多州Colorado 缩写：CO 得克萨斯州Texas 缩写：TX 哥伦比亚特区Columbia 缩写：DC? 犹他州Utah 缩写：UT 康涅狄格州Connecticut 缩写：CT 佛蒙特州Vermont 缩写：VT 特拉华州Delaware 缩写：DE 弗吉尼亚州Virgina 缩写：VA 佛罗里达州Florida 缩写：FL 华盛顿州Washington 缩写：WA 佐治亚州Georgia 缩写：GA 西弗吉尼亚州West Virginia 缩写：WV 夏威夷州Hawaii 缩写：HI 威斯康星州Wisconsin 缩写：WI 爱达荷州Idaho 缩写：ID 怀俄明州Wyoming 缩写：WY 伊利诺伊州Illinois 缩写：IL 印弟安纳州Indiana 缩写：IN 爱荷华州Iowa 缩写：IA 堪萨斯州Kansas 缩写：KS 肯塔基州Kentucky 缩写：KY 路易斯安那州Louisiana 缩写：LA 缅因州Maine 缩写：ME 马里兰州Maryland 缩写：MD 马萨诸塞州Massachusetts 缩写：MA
美国各州缩写 Alaska-Kansas Alaska AK Alabama AL Arkansas AR American Samoa AS Arizona AZ California CA Colorado CO Connecticut CT Canal Zone CZ District of Columbia DC Delaware DE Florida FL Georgia GA Guam GU Hawaii HI Iowa IA Idaho ID Illinois IL Indiana IN Kansas KS Kentucky-Ohio Kentucky KY Louisiana LA Massachusetts MA Maryland MD Maine ME Michigan MI Minnesota MN Missouri MO Mississippi MS Montana MT North Carolina NC North Dakota ND Nebraska NE Nevada NV New Hampshire NH New Jersey NJ New Mexico NM New York NY Northern Mariana Islands CM Ohio OH Oklahoma-Wyoming Oklahoma OK Oregon OR Pennsylvania PA Puerto Rico PR Rhode Island RI South Carolina SC South Dakota SD Tennessee TN Trust Territories TT Texas TX US Overseas Military AA、AE、AP Utah UT Virginia VA Virgin Islands VI Vermont VT Washington WA Wisconsin WI West Virginia WV Wyoming WY
美国各州英文简写 美国各州的邮政缩写，英中文全称以及首府，按英文缩写排列： AL Alabama 亚拉巴马州蒙哥马利 AK Alaska 阿拉斯加州朱诺 AZ Arizona 亚利桑那州凤凰城 AR Arkansas 阿肯色州小石城 CA California 加利福尼亚州沙加缅度 CO Colorado 科罗拉多州丹佛 CT Connecticut 康涅狄格州哈特福德 DE Delaware 特拉华州多佛 FL Florida 佛罗里达州塔拉哈西 GA Georgia 佐治亚州亚特兰大 HI Hawaii 夏威夷州檀香山 ID Idaho 爱达荷州博伊西 IL Illinois 伊利诺州斯普林菲尔德 IN Indiana 印地安那州印地安那波利斯 IA Iowa 艾奥瓦州得梅因 KS Kansas 堪萨斯州托皮卡
KY Kentucky 肯塔基州法兰克福 LA Lousiana 路易斯安那州巴吞鲁日 ME Maine 缅因州奥古斯塔 MD Maryland 马里兰州安那波利斯 MA Massachusetts 马萨诸塞州波士顿 MI Michigan 密歇根州兰辛 MN Minnesota 明尼苏达州圣保罗 MS Mississippi 密西西比州杰克逊 MO Missouri 密苏里州杰弗逊市 MT Montana 蒙大拿州海伦那 NE Nebraska 内布拉斯加州林肯 NV Nevada 内华达州卡森市 NH New Hampshire 新罕布什尔州康科德NJ New Jersey 新泽西州特伦顿 NM New Mexico 新墨西哥州圣大非 NY New York 纽约州奥尔巴尼 NC North Carolina 北卡罗来纳州罗利 ND North Dakota 北达科他州俾斯麦 OH Ohio 俄亥俄州哥伦布 OK Oklahoma 俄克拉何马州奥克拉荷马市OR Oregon 俄勒冈州塞勒姆 PA Pennsylvania 宾夕法尼亚州哈里斯堡
有朋友问我，如何做作有个性化的动画图？做动画的方法有很多种，我们就从简单学起，介绍如何用Photoshop和Imageready制作动画。 效果图 1）新建文件 点击“文件”—“新建”—“FUPING111”，设定宽度、高度、名称，“背景内容”选透明”，新建一个300(宽)×150(高)象素即可，具体尺寸可以按自己需要设定。 2）制作所需的图片或素材 在photoshop里打开所需的图片，这里只需要一张背景图，再输入您所要显示的文字如图1。鼠标左键点击背景图片，按“ Ctrl+A”，图四周出现流动的虚线框，再 Ctrl+C拷贝该图片。鼠标左键点击刚才新建的“FUPING111”文件，按“Ctrl+V”，就将图片粘贴进“FUPING111”中了。（如果图片不是300×150象素，那么还需要把图片制作成300×150象素） 图1 3）进入动画软件
点击photoshop的工具条最下方的图标。进入Imageready软件,如图2。 图2 如果这个步骤无法完成，表示您安装的是 photoshop迷你版本，请重新下载完整版的 photoshop。正常情况下， Imageready在左下角有个“动画窗口”，右下角有“图层窗口”。如果找不到这 2个窗口，请在软件菜单“窗口”菜单中勾选显示出来。 图3 4）动画制作
进入 Imagereadym，在“动画”对话框内默认为一帧。我们初步的设计为文字从左侧进入图片中央，停顿5秒，再从右侧滚出。所以先将第一桢的文字使用移动工具，将文字拖到左侧图框外。点“复制桢”按钮，复制第二桢，在第二桢把文字拖到图框中央，见图4 图4 按住“SHIFT”键，选取1、2桢，点“过渡”按钮，出现“过渡”对话框，在“要添加的桢”狂内，填入“10”，增加10桢的过渡。添加的过渡桢数越多，动画过渡的越自然，但动画文件越大。见图5
美国各个州的缩写、全称、中文译名及首府Alabama AL 亚拉巴马 Montgomery 蒙哥马利Alaska AK 阿拉斯加 Juneau 朱诺 Arizona AZ 亚利桑那 Phoenix 菲尼克斯Arkansas AR 阿肯色 Little Rock 小石城California CA 加利福尼亚 Sacramento 萨克拉门托Colorado CO 科罗拉多 Denver 丹佛Connecticut CT 康涅狄格 Harford 哈特福德Delaware DE 特拉华 Dover 多佛 District of columbia DC 哥伦比亚特区 Florida FL 佛罗里达 Tallahassee 塔拉哈西Georgia GA 佐治亚 Atlanta 亚特兰大Hawaii HI 夏威夷 Honolulu 火奴鲁鲁Idaho ID 爱达荷 Boise 博伊西 Illinois IL 伊利诺斯 Springfield 斯普林菲尔德 Indiana IN 印第安纳 Indianapolis 印第安纳波利斯 Iowa IA 爱荷华 Des moines 得梅因Kansas KS 堪萨斯 Topeka 托皮卡 Kentucky KY 肯塔基 Frankfort 法兰克福Louisiana LA 路易斯安那 Baton Rouge 巴吞鲁日
Maine ME 缅因 Augusta 奥古斯塔Maryland MD 马里兰 Annapolis 安那波利斯Massachusetts MA 马萨诸塞 Boston 波士顿 Michigan MI 密歇根 Lansing 兰辛 Minnesota MN 明尼苏达 St.Paul 圣保罗Mississippi MS 密西西比 Jackson 杰克逊Missouri MO 密苏里 Jefferson City 杰斐逊城Montana MT 蒙大拿 Helena 海伦娜 Nebraska NE 内布拉斯加 Lincoln 林肯 Nevada NV 内华达 Carson City 卡森城 New Hampshire NH 新罕布什尔 Concord 康科德 New Jeresy NJ 新泽西 Trenton 特伦顿 New Mexico NM 新墨西哥 Santa Fe 圣菲 New York NY 纽约 Albany 奥尔巴尼NorthCarolina NC 北卡罗来纳 Raleigh 罗利 North Dakota ND 北达科他 Bismarck 俾斯麦 Ohio OH 俄亥俄 Columbus 哥伦布Oklahoma OK 俄克拉何马 Oklahoma City 俄克拉何马城 Oregon OR 俄勒冈 Salem 塞勒姆Pennsylvania PA 宾夕法尼亚 Harrisburg 哈里斯堡Rhode Island RI 罗得岛 Providence 普罗维登斯
NRW美国各个州的缩写、全称、中文译名及首府 Alabama AL 亚拉巴马Montgomery 蒙哥马利 Alaska AK 阿拉斯加Juneau 朱诺 Arizona AZ 亚利桑那Phoenix 菲尼克斯 Arkansas AR 阿肯色Little Rock 小石城 California CA 加利福尼亚Sacramento 萨克拉门托Colorado CO 科罗拉多Denver 丹佛 Connecticut CT 康涅狄格Harford 哈特福德 Delaware DE 特拉华Dover 多佛 District of columbia DC 哥伦比亚特区 Florida FL 佛罗里达Tallahassee 塔拉哈西 Georgia GA 佐治亚Atlanta 亚特兰大 Hawaii HI 夏威夷Honolulu 火奴鲁鲁 Idaho ID 爱达荷Boise 博伊西 Illinois IL 伊利诺斯Springfield 斯普林菲尔德Indiana IN 印第安纳Indianapolis 印第安纳波利斯Iowa IA 爱荷华Des moines 得梅因 Kansas KS 堪萨斯Topeka 托皮卡 Kentucky KY 肯塔基Frankfort 法兰克福 Louisiana LA 路易斯安那Baton Rouge 巴吞鲁日 Maine ME 缅因Augusta 奥古斯塔 Maryland MD 马里兰Annapolis 安那波利斯Massachusetts MA 马萨诸塞Boston 波士顿 Michigan MI 密歇根Lansing 兰辛 Minnesota MN 明尼苏达 St.Paul 圣保罗 Mississippi MS 密西西比Jackson 杰克逊 Missouri MO 密苏里Jefferson City 杰斐逊城Montana MT 蒙大拿Helena 海伦娜 Nebraska NE 内布拉斯加Lincoln 林肯 Nevada NV 内华达Carson City 卡森城 New Hampshire NH 新罕布什尔Concord 康科德 New Jeresy NJ 新泽西Trenton 特伦顿 New Mexico NM 新墨西哥Santa Fe 圣菲 New York NY 纽约Albany 奥尔巴尼NorthCarolina NC 北卡罗来纳Raleigh 罗利 North Dakota ND 北达科他Bismarck 俾斯麦 Ohio OH 俄亥俄Columbus 哥伦布 Oklahoma OK 俄克拉何马Oklahoma City 俄克拉何马城Oregon OR 俄勒冈Salem 塞勒姆 Pennsylvania PA 宾夕法尼亚Harrisburg 哈里斯堡 Rhode Island RI 罗得岛Providence 普罗维登斯SouthCarolina SC 南卡罗来纳Columbia 哥伦比亚
小学信息技术《制作简单的动画》教学设计 教学系统设计： 本课教学是人教版五年级《信息技术》五年级上册教材第九课的内容。这一节是对flash 丰富的艺术功能的展现，对学生利用flash设计多彩的动画效果有着重要的作用，特别是对于培养学生的审美观点和能力、提升学生的审美情趣更是举足轻重。从内容角度考虑：学生在前面学过在flash中插入文字、图片,加上关键帧等一系列效果，做成一个多彩的动画效果。；从学生兴趣分析：通过flash制作多彩的动画，对学生来讲具有一定的趣味性，可以通过合适的引导完成本节内容；从教学引入分析：对本节内容，部分教学设计是通过动画等形式来穿插进行，增加了学生的学习兴趣，也能在愉快的氛围中完成教学任务。 教学目标 知识目标：●了解flash8的工作界面。 ●知道帧、关键帧的概念 ●掌握各种面板的属性。 技能目标：●通过关键帧制作一个简单的动画 ●对多个对象创建动画。 情感目标：●通过作品的展示，激发学生的求知愿望。 ●要求学生自己独立完成作品的创作，培养学生的信息素养。
教学重难点 重点：关键帧的使用 难点：对多个对象创作动画 教学策略 支架式教学策略：搭脚手架，引出主题进入情境，教师演示独立探索，解难释疑作品展示，效果评价 教学准备 ●人教版信息技术五年级上册《制作简单的动画》课件 ●微格教室 教学过程 一、情境导入，激发兴趣 师： Flash软件是现在最流行的网络动画制作软件，利用它制作的作品不仅声情并茂，而且文 件特别小，传输速度快。网络上的许多动画短片、小游戏、广告条都是用它制作的。Flash 的设计界面友好，操作方便。下面，我们就来体验一下Flash动画制作的无穷魅力吧！ 揭示课题——制作简单动画 二、知识新授
美国51州全称及对应简称和中文 美国51州全称及对应简称和中文给大家提供一下美国51州全称及对应简称和中文,方便大家做任务时需要: 1. Alabama 1. AL 1. 阿拉巴马州 2. Alaska 2. AK 2. 阿拉斯加州 3. Arizona 3. AZ 3. 亚利桑那州 4. Arkansas 4. AR 4. 阿肯色州 5. California 5. CA 5. 加利福尼亚州 6. Colorado 6. CO 6. 科罗拉多州 7. Connecticut 7. CT 7. 康涅狄格州 8. Delaware 8. DE 8. 德拉华州 9. District of Columbia 9. DC 9. (华盛顿)哥伦比亚特区 10. Florida 10. FL 10. 佛罗里达州 11. Georgia 11. GA 11. 乔治亚州 12. Hawaii 12. HI 12. 夏威夷州 13. Idaho 13. ID 13. 爱达荷州 14. Illinois 14. IL 14. 伊利诺州 15. Indiana 15. IN 15. 印地安那州 16. Iowa 16. IA 16. 衣阿华州 17. Kansas 17. KS 17. 堪萨斯州 18. Kentucky 18. KY 18. 肯塔基州 19. Louisiana 19. LA 19. 路易斯安那州 20. Maine 20. ME 20. 缅因州 21. Maryland 21. MD 21. 马里兰州 22. Massachusetts 22. MA 22. 麻萨诸塞州 23. Michigan 23. MI 23. 密执安州 24. Minnesota 24. MN 24. 明尼苏达州 25. Mississippi 25. MS 25. 密西西比州 26. Missouri 26. MO 26. 密苏里州 27. Montana 27. MT 27. 蒙大拿州 28. Nebraska 28. NE 28. 内布拉斯加州 29. Nevada 29. NV 29. 内华达州 30. New Hampshire 30. NH 30. 新罕布什尔州 31. New Jersey 31. NJ 31. 新泽西州 32. New Mexico 32. NM 32. 新墨西哥州 33. New York 33. NY 33. 纽约州 34. North Carolina 34. NC 34. 北卡罗来纳州 35. North Dakota 35. ND 35. 北达科他州 36. Ohio 36. OH 36. 俄亥俄州 37. Oklahoma 37. OK 37. 俄克拉荷马州 38. Oregon 38. OR 38. 俄勒冈州 39. Pennsylvania 39. PA 39. 宾夕法尼亚州 40. Rhode Island 40. RI 40. 罗得岛州 41. South Carolina 41. SC 41. 南卡罗来纳州
美国U S A各州的缩写及 主要城市 Revised by BLUE on the afternoon of December 12,2020.
美国各州的缩写及主要城市 一、亚拉巴马州 英文州名(缩写)：Alabama (AL) 区号：205 – 251 – 256 – 334 主要城市： 1、伯明翰(Birmingham) 2、蒙哥马利(Montgomery) 3、亨次维尔(Huntsville) 4、土斯卡鲁沙(Tuscaloosa) 5、木比耳(Mobile) 二、阿拉斯加州 英文州名(缩写)：Alaska (AK) 区号：907 主要城市： 1、朱诺(Juneau) 2、安克拉奇(Anchorage) 3、费尔班克斯(Fairbanks) 三、亚利桑那州
英文州名(缩写)：Arizona (AZ) 区号：480 – 520 – 602 – 623 – 928 主要城市： 1、菲尼克斯[凤凰城](Phoenix) 2、吐桑(Tucson) 3、孟沙(Mesa) 四、阿肯色州 英文州名(缩写)：Arkansas (AR) 区号：501 – 870 主要城市： 1、小石城(Little Rock) 2、菲页维尔(Fayetteville) 五、加利福尼亚州 英文州名(缩写)：California (CA) 区号：209 – 213 – 310 – 323 – 408 – 415 – 510 – 530 – 559 –562 – 619 – 626 – 650 – 661 – 707 – 714 – 760 – 805 – 818 –831 – 858 – 909 – 916 – 925 – 949 主要城市： 1、萨克拉门托(Sacramento) 2、索诺马(Sonoma) 3、圣荷西(San Jose)
美国州名及缩写州府 AL Alabama[??l??b?m?] 亚拉巴马州, Montgomery蒙哥马利, Mobile莫比尔, Birmingham伯明翰, Huntsville亨茨维尔 AK Alaska[??l?sk?] 阿拉斯加州(1872年，交易价格720万美元), Juneau朱诺AZ Arizona [??ri?z?un?] 亚利桑那州, Phoenix [?fi:n?ks] 菲尼克斯(凤凰城); Tucson[tu:?s?n] 图森 AR Arkansas阿肯色州, Little rock小石城; Hot Springs 温泉城 CA California [?k?l??f?:nj?] 加利福尼亚州, Sacramento [?s?kr??ment?u] 萨克拉门托(沙加缅度)；San Francisco旧金山(三藩市);Oakland奥克兰; Los Angeles洛杉矶; San Diego[?s?ndi(:)?eiɡ?u] 圣迭戈 CO Colorado [?k?l??rɑ:d?u]科罗拉多州, Denver丹佛, Colorado Springs科罗拉多斯普林斯 CT Connecticut[k??netik?t]康涅狄格州, Hartford哈特福德, New Haven 纽罕文DE Delaware特拉华州, Dover多佛, Wilmington威明顿, Newark纽瓦克 FL Florida佛罗里达州Tallahassee[?t?l??h?si]塔拉哈西, Miami 迈阿密, Jacksonville[?d??ks?nvil] 杰克逊维尔, Fort Lauderdale劳德尔堡,Tampa坦帕GA Georgia佐治亚州, Atlanta[?t?l?nt?]亚特兰大, Macon梅肯 HI Hawaii [h??wɑ:i:] 夏威夷州, Honolulu[?h?n??lu:lu:] 檀香山(火奴鲁鲁) ID Idaho[?aid?h?u]爱达荷州, Boise博伊西, Pocatello 博卡特洛, Idaho Falls 爱达荷福尔斯, IL Illinois伊利诺伊州, Chicago芝加哥 IN Indiana印第安纳州, Indianapolis印第安纳波利斯, Evansville埃文斯维尔 IA Iowa [?ai?w?]艾奥瓦州(爱荷华州), Des Moines得梅因, Davenport达芬波特, Cedar Rapids思德激流, Sioux City 苏城 KS Kansas堪萨斯州, Topeka托皮卡, Wichita威奇托, Kansas City堪萨斯城 KY Kentucky肯塔基州, Frankfort法兰克福, LA Louisiana路易斯安那州, Baton Rouge[?b?tn ?ru:?] 巴吞鲁日, Shreveport[??ri:vp?:t] 什里夫波特; New Orleans[nju: ??:li?nz]新奥尔良 ME Maine缅因州, Augusta奥古斯塔, Portland 波特兰，Auburn欧本, Bar Harbor 巴尔港, Lewiston 路易斯顿, Bangor 班哥尔 MD Maryland马里兰州, Annapolis安纳波利斯, Baltimore 巴尔的摩 MA Massachusetts马萨诸塞州, Boston波士顿, Worcester 伍斯特, Springfield斯普林菲尔德, New Bedford 新贝的福德 MI Michigan密歇根州, Lansing兰辛, Grand Rapids大激流城
教你简单制作动画图片的小方法
有朋友问我，如何做作有个性化的动画图？做动画的方法有很多种，我们就从简单学起，介绍如何用Photoshop和Imageready制作动画。 效果图 1）新建文件 点击“文件”—“新建”—“FUPING111”，设定宽度、高度、名称，“背景内容”选透明”，新建一个300(宽)×150(高)象素即可，具体尺寸可以按自己需要设定。 2）制作所需的图片或素材
在photoshop里打开所需的图片，这里只需要一张背景图，再输入您所要显示的文字如图1。鼠标左键点击背景图片，按“ Ctrl+A”，图四周出现流动的虚线框，再 Ctrl+C拷贝该图片。鼠标左键点击刚才新建的“FUPING111”文件，按“Ctrl+V”，就将图片粘贴进“FUPING111”中了。（如果图片不是300×150象素，那么还需要把图片制作成300×150象素） 图1 3）进入动画软件 点击photoshop的工具条最下方的图标。进入Imageready软件,如图2。
图2 如果这个步骤无法完成，表示您安装的是 photoshop迷你版本，请重新下载完整版的photoshop。正常情况下， Imageready在左下角有个“动画窗口”，右下角有“图层窗口”。如果找不到这 2个窗口，请在软件菜单“窗口”菜单中勾选显示出来。
图3 4）动画制作 进入 Imagereadym，在“动画”对话框内默认为一帧。我们初步的设计为文字从左侧进入图片中央，停顿5秒，再从右侧滚出。所以先将第一桢的文字使用移动工具，将文字拖到左侧图框外。点“复制桢”按钮，复制第二桢，在第二桢把文字拖到图框中央，见图4
缩写州名州名汉译首府首府汉译 AL Alabama 亚拉巴马Montgomery 蒙哥马利AK Alaska 阿拉斯加Juneau 朱 AZ Arizona 亚利桑那Phoenix 菲尼克斯AR Arkansas 阿肯色Little Rock 小石城CA California 加利福尼亚Sacramento 萨克拉门托 CO Colorado 科罗拉多Denver 丹佛 CT Connecticut 康涅狄格Harford 哈特福德DE Delaware 特拉华Dover 多佛 DC District of Columbia 哥伦比亚特区 FL Florida 佛罗里达Tallahassee 塔拉哈西GA Georgia 佐治亚Atlanta 亚特兰大HI Hawaii 夏威夷Honolulu 火奴鲁鲁ID Idaho 爱达荷Boise 博伊西 IL Illinois 伊利诺斯Springfield 斯普林菲尔德IN Indiana 印第安纳Indianapolis 印第安纳波利斯IA Iowa 爱荷华Des moines 得梅因 KS Kansas 堪萨斯Topeka 托皮卡KY Kentucky 肯塔基Frankfort 法兰克福LA Louisiana 路易斯安那Baton Rouge 巴吞鲁日ME Maine 缅因Augusta 奥古斯塔
MD Maryland 马里兰Annapolis 安那波利斯MA Massachusetts 马萨诸塞Boston 波士顿MI Michigan 密歇根Lansing 兰辛MN Minnesota 明尼苏达St.Paul 圣保罗MS Mississippi 密西西比Jackson 杰克逊MO Missouri 密苏里Jefferson City 杰斐逊城MT Montana 蒙大拿Helena 海伦娜NE Nebraska 内布拉斯加Lincoln 林肯NV Nevada 内华达Carson City 卡森城NH New Hampshire 新罕布什尔Concord 康科德NJ New Jersey 新泽西Trenton 特伦顿NM New Mexico 新墨西哥Santa Fe 圣菲NY New York 纽约Albany 奥尔巴尼NC North Carolina 北卡罗来纳Raleigh 罗利ND North Dakota 北达科他Bismarck 俾斯麦OH Ohio 俄亥俄Columbus 哥伦布OK Oklahoma 俄克拉荷马 Oklahoma City 俄克拉何马城OR Oregon 俄勒冈 Salem 塞勒姆PA Pennsylvania 宾夕法尼亚Harrisburg 哈里斯堡RI Rhode Island 罗得岛Providence 普罗维登斯SC South Carolina 南卡罗来纳Columbia 哥伦比亚SD South Dakota 南达科他Pierre 皮尔
第16课制作简单动画（3课时-1）初步了解循环结构程序设 软件默认的舞 舞台上默认的角 。同学们也可以自己设计舞台的背景和舞台中 教材配套光盘中提供了丰富的舞台背景、角色造型等素这些资源都可以在设计脚本 导入角色最好用营造勤劳的小蜜蜂在美丽一．替换背景图片 ①单击“角色列表”区中 的“舞台”图标。 ②单去脚本区中的“多个 背景”选项卡。 ③单去“导入”按钮，弹 出“导入背景”对话框。 ④找到教材配套光盘中的 风景图片，并单击“确定”。 ①删除原来的舞台背 景。 激发兴趣
第16课制作简单动画（3课时-2） 设计角色动画就是按照自己的想法为角色添加相关的命令模块。 同学们可以先从简单的动作开始设计，逐步丰富动画的效果。1．角色的移动动画P99 操作任务为“小蜜蜂”设计移动动画 探索实践P99 ←→方式下，“小蜜蜂”移动过程中若碰到舞台边缘时会自动左右翻转。分别选择“角色信息区中的旋转、停止两种力式，比较“小蜜蜂’’碰到舞台边缘时的动画效果。 2.变换角色造型P100 如果能让“小蜜蜂”的翅膀振动起来，动画效果会更生动。1 为“小蜜蜂”设计移动动画 ① 切换到脚本编辑状态。 ② “当绿旗被点击”命令模块拖到脚本区。 ③ 为脚本程序添加移动 步命令模块，移动参数改为“ ④ 使角色碰到舞台边缘时自动掉转运动方向。 ⑤ 中的←→，设定只允许角色左右翻转。 ⑥ 程序动画效果。 探索实践 分别选择“角色信息区中的旋转、停止两种力式，比较 边缘时的动画效果。
飞舞的翅膀有不同的外观，这就是角色的造型变换。角色的造型可以分为单一造型和多个造型。多个造型的角色在运行脚本程序过程中，可以交替变换不同造型。 操作任务变换小蜜蜂造型 程序中加入切换角色造型的命令模块，可以让角色自动变换造型。 思考探索P101 观察“造型?”和“造型2”有什么不同，想一想为什么这个动画需要两个造型。操作任务变换小蜜蜂造型 ①单去“角色列表”中 的“角色厂图标。 ②用教材配套光盘中的 素材库，如图3—16所示， 添加“小蜜蜂”的第二个 造型。 ③换到“脚本”选项卡， 将“外观”模块库中的“下 一个造型”命令模块 插入到脚本程序中，实现 角色多个造型的交替变 换。 ④测试脚本程序。 思考探索 观察动画效果，还需要进 行哪些调整。 利用探究式学习 提高学生学习兴 趣，培养学生动 手动脑的能力