留学文书自荐书代写
留学硕士论文代写
SCI期刊ISTP期刊EI论文代写
留学申请推荐信个人陈述代写
留学研究计划书代写
留学论文作业代写修改
英语 English
日语 日本語
韩语한국의
法语 Français
德语 Deutsch
俄语 Pусский
西语 Español
意语 Italiano
·英语论文 ·日语论文
·韩语论文 ·德语论文
·法语论文 ·俄语论文

名称:智尚工作室
电话:0760-86388801
传真:0760-85885119
地址:广东中山市学院路1号
网址:www.zsfy.org
E-Mail:cjpdd@vip.163.com

商务QQ:875870576
微信二维码

业务联系
隐藏文章
用户体验The user experience building a quality application
添加时间: 2012-12-19 12:31:38 来源: 作者: 点击数:5270


The user experience

6.1 Getting it right: building a quality application

Usability is an especially hot topic for Ajax because web app users can be an extremely fickle bunch. The downside of being able to download and run your app with zero effort is that the users have invested no time and effort in it when they start to use the application and will be willing to throw it away and move on to the next of the 8 billion web pages that Google can point them to. To complicate matters further, with Ajax we are seeing the convergence of two different usability traditions, namely the desktop application and the web page. Getting the mixture right can be quite a challenge, and failing to get it right can consign your hard work to obscurity.

In chapter 1, we looked at usability from the users’ point of view. What do they want in an application? And what are they willing to put up with? Let’s turn the question around now and ask what qualities we need in our code to meet the goal of usability. With this as a starting point, we can figure out what we can do in practical terms to make our application work. The following sections detail a number of key features that add quality to your application.

6.1.1 Responsiveness
The most basic frustration that a computer user can suffer from is to have workflow interrupted while the computer struggles to catch up with him. Basic design mistakes, such as locking up the entire user interface while writing some lengthy configuration file to disk, can cause the user to lose track of what he is doing and force him to make the mental leap between the domain model in which he is engaged to the harsh reality of computer hardware.

When looking at responsiveness, it can be important to understand your target audience and its typical system setups. In the case of writing a configuration file, the speed may be acceptable on the developer’s high-speed 7200-RPM SATA disk drive on the local workstation, but the customer writing the file to a congested network share or a USB thumb drive may have a different experience. In the specific case of web app development, a similar mistake is often made in only testing the application running over the loopback interface, that is, the web server running on the same development machine as the web browser. This doesn’t give a useful evaluation of network latency issues, and all web apps ought to be either tested over a real LAN or WAN or simulated using a traffic-shaping tool.

Beyond network issues, the performance of the client code can make a huge difference to responsiveness. Performance is a big issue, so we’ll defer a closer look at it to chapter 7.

6.1.2 Robustness
An application is robust if it can withstand the usual conditions encountered at a busy workstation. How does it cope with a temporary network outage? If a badly behaved program hogs the CPU for five minutes, will your application still work afterwards? At one recent project that I was involved in, we would test our application’s robustness by pounding randomly on the keyboard for 10 seconds or so, and by “scribbling” the mouse across the page while clicking it. A crude sort of test—but effective—and quite good fun!

What can such a test reveal? For one thing, it can highlight inefficiencies in event-handler code. Keypresses, mouse moves, and the like need to return quickly, since they are apt to be called very frequently. Further, they can reveal unintentional dependencies between components. A particular condition may arise in a GUI, for example, where a modal dialog is blocking access to the main application, but an open menu item is blocking access to the modal dialog. If such a situation depends on precise timing in the opening of the dialog and the menu, it might take a single user two months of daily work to discover it. Once released to an audience of several thousand, however, it might start showing up within hours and be extremely hard to reproduce from field reports. Identifying the problem up front, and correcting it, increases the overall robustness of the application.

There is more to robustness than randomly thumping the keyboard. Just as valuable is the process of watching someone other than the developer trying to use the application. In the case of a complete newcomer, this can provide helpful information on the overall usability design, but it is also useful to let someone closely acquainted with the domain knowledge, even the product, test-drive a new bit of functionality. When the person who wrote the code runs the program, she can “see” the code behind it and may subconsciously avoid specific combinations of actions or particular actions in specific contexts. The end user won’t have this insider knowledge, of course, and neither will the developer sitting next to you (unless you do pair programming). Getting someone else to informally run through your app workflow can help to build up robustness early on.

6.1.3 Consistency
As we already noted, the usability patterns of Ajax are still evolving from a mishmash of desktop application and web browser conventions. Some Ajax toolkits, such as Bindows, qooxdoo, and Backbase, even present widget sets deliberately styled to look like desktop application buttons, trees, and tables. The right answer to this conundrum is still being worked out by webmasters, usability gurus, and everyday users of the Web as it continues to evolve. In the meantime, the best advice available is to keep things consistent. If one part of your application uses web-style single clicks to launch pop-up windows, and another part requires double-clicks on similar-looking icons, your user will quickly become confused. And if you must have a talking pig that guides your users around the site, make sure that it doesn’t suddenly change its accent, costume, or hairstyle halfway through!

From the point of view of your codebase, consistency and reuse go hand in hand. If you cut and paste functionality from one location to another, and then respond to a change request in three copies of the button-rendering code but miss a fourth, the consistency of your interface will erode over time. If there is only one copy of the button-rendering code that everyone uses, then the consistency of your application is likely to remain high. This applies not only to visual UI behavior but also to less-visible parts of the interface, such as network timeouts and responses to bad data.

6.1.4 Simplicity
Finally, we need to stress the importance of simplicity. Ajax allows you to do a number of wild and creative things, the likes of which have never been seen in a web page before. Some of these things have never been seen because the necessary technology is only just arriving on the scene. In other cases, there are good reasons for not implementing a feature. Spring-loaded menus that bounce onto the screen and gradually dampen their oscillations may be great fun to code and great fun for a short-term user dropping by for five minutes to let off steam. If the user is going to use the application for several hours a day, though, she is less likely to appreciate the fun by the day’s end.

It is always worth asking whether a new feature will actually improve the end experience. In many cases with Ajax, the answer will be yes, and the developer can concentrate on coding features that will be genuinely beneficial.

6.1.5 Making it work
It’s probably the case that your code doesn’t exhibit all the features we just mentioned.

Mine certainly doesn’t. These are merely ideals that we’ve presented. Making the effort to move toward these ideals can pay big dividends when it comes to maintaining your codebase in the future, and refactoring existing code can introduce these qualities as you go along. Choosing where to concentrate the effort is something of a black art, and the only way to get good at it is by practicing. If you’re new to refactoring, start with something small and gradually work outward. Remember, refactoring is an incremental process, and you can add quality to your code without pulling it apart and leaving bits on the floor for weeks on end.
In the remainder of this chapter, we’ll look at some specific features that you can build into Ajax applications. A large part of the chapter focuses on notification frameworks, which are ways of keeping the user informed while background processes such as calculations or network requests take place. By providing the user with a visual cue that the process is under way, we improve the responsiveness of the application. By running all such notifications through a common framework, we ensure that presentation is consistent and make it simple for the user to work with the notifications because everything works in the same way. Let’s start off by looking at the various ways in which we can notify the user of events taking place within the application.

6.2 Keeping the user informed

In an Ajax application, we may often need to run off across the network and fetch some resources from the server and then pick up the results in a callback function and do something with them. If we were handling server requests synchronously, we would have a relatively easy time working out how to handle this in user interface terms. The request would be initiated, the entire user interface would lock up and stop responding, and when the results come back from the server, the interface would update itself and then start responding to input. What’s good for the developer here is lousy for the user, of course, so we make use of an asynchronous request mechanism. This makes the business of communicating server updates through the user interface that much more complicated.

6.2.1 Handling responses to our own requests
Let’s pick up a concrete example to work with. The planetary information viewer that we developed in chapter 5 allowed the user to update a couple of editable properties for planets: the diameter and the distance from the sun (see section 5.5).

These updates are submitted to the server, which then responds, saying whether it has accepted or rejected them. With the introduction of the command queue concept in section 5.5.3, we allowed each server response to carry acknowledgments to several updates from a given user. A sample XML response document follows, showing one successful and one unsuccessful command:



message='value out of range'/>

From the user’s perspective, she edits the property and then moves on to some other task, such as editing the list of facts associated with that planet or even staring out of the window. Her attention is no longer on the diameter of the planet Mercury. Meanwhile, in the background, the updated value has been wrapped in a JavaScript Command object, which has entered the queue of outgoing messages and will be sent to the server shortly thereafter. The Command object is then transferred to the “sent” queue and is retrieved when the response returns, possibly along with a number of other updates. The Command object is then responsible for processing the update and taking appropriate action.

Let’s recap where we had left this code before we start refactoring. Here is our implementation of the Command object’s parseResponse() method, as presented in chapter 5:

planets.commands.UpdatePropertyCommand
.parseResponse=function(docEl){
var attrs=docEl.attributes;
var status=attrs.getNamedItem("status").value;
if (status!="ok"){
var reason=attrs.getNamedItem("message").value;
alert("failed to update "+this.field
+" to "+this.value+"\n\n"+reason);
}
}

This is good proof-of-concept code, ripe for refactoring into something more polished. As it stands, if the update is successful, nothing happens at all. The local domain model was already updated before the data was sent to the server, so everything is assumed to be in sync with the server’s domain model. If the update fails, then we generate an alert message. The alert message is simple for the developer but makes for poor usability, as we will see.

Let’s return to our user, who is probably no longer thinking about the albedo of the planet Mercury. She is suddenly confronted with a message in an alert box saying, “Failed to update albedo to 180 value out of range,” or something similar. Taken out of context, this doesn’t mean very much. We could upgrade our error message to say “Failed to update albedo of Mercury...,” but we would still be interrupting the user’s workflow, which was the reason that we switched to asynchronous message processing in the first place. We would, in this particular case, also be creating a more serious problem. Our editable fields implementation uses the onblur event to initiate the process of submitting data to the server. The onblur() method is triggered whenever the text input field loses focus, including when it is taken away by an alert box. Hence, if our user has moved on to editing another property and is midway through typing into the second textbox, our alert will result in the submission of partial data and either mess up the domain model on the server or generate an error—and a further alert box if our validation code catches it! A more elegant solution than the alert box is needed. We’ll develop one shortly, but first let’s further complicate the picture by considering what other users are up to while we make our requests to the server.

6.2.2 Handling updates from other users
Our planetary viewer application allows more than one user to log in at once, so presumably other users may be editing data while we are. Each user would presumably like to be informed of changes made by other users more or less as they happen. Most Ajax applications will involve more than one browser sharing a domain model, so this is again a fairly common requirement.

We can modify our XML response, and the Command queue object, to cope with this situation in the following way. For each update to the server-side model, we generate a timestamp. We modify the server-side process that handles updates to also check the domain model for recent updates by other users, and attach them to the response document, which might now look like this:





Alongside the tags, which are identified by the ID of the Command object in the sent queue, there is an tag, which in this case denotes that the distance from the sun of Venus has been set to a value of 0.76 by another user called Jim. We have also added an attribute to the top-level tag, the purpose of which we explain shortly.

Previously, our command queue sent requests to the server only if there were commands queued up. We would need to modify it now to poll the server even if the queue were empty, in order to receive updates. Implementing this touches upon the code in several places. Listing 6.1 shows the revised CommandQueue object, with the changes in bold.

net.cmdQueues=new Array();
net.CommandQueue=function(id,url,onUpdate,freq){
this.id=id;
net.cmdQueues[id]=this;
this.url=url;
this.queued=new Array();
this.sent=new Array();
this.onUpdate=onUpdate;
if (freq){
this.repeat(freq);
}
this.lastUpdateTime=0;
}
net.CommandQueue.prototype.fireRequest=function(){
if (!this.onUpdate && this.queued.length==0){
return;
}
var data="lastUpdate="+this.lastUpdateTime+"&data=";
for(var i=0;ivar cmd=this.queued[i];
if (this.isCommand(cmd)){
data+=cmd.toRequestString();
this.sent[cmd.id]=cmd;
}
}
this.queued=new Array();
this.loader=new net.ContentLoader(
this.url,
net.CommandQueue.onload,net.CommandQueue.onerror,
"POST",data
);
}
net.CommandQueue.onload=function(loader){
var xmlDoc=net.req.responseXML;
var elDocRoot=xmlDoc.getElementsByTagName("responses")[0];
var lastUpdate=elDocRoot.attributes.getNamedItem("updateTime");
if (parseInt(lastUpdate)>this.lastUpdateTime){
this.lastUpdateTime=lastUpdate;
}
if (elDocRoot){
for(i=0;ielChild=elDocRoot.childNodes[i];
if (elChild.nodeName=="command"){
var attrs=elChild.attributes;
var id=attrs.getNamedItem("id").value;
var command=net.commandQueue.sent[id];
if (command){
command.parseResponse(elChild);
}
}else if (elChild.nodeName=="update"){
if (this.implementsFunc("onUpdate")){
this.onUpdate.call(this,elChild);
}
}
}
}
}
net.CommandQueue.prototype.repeat=function(freq){
this.unrepeat();
if (freq>0){
this.freq=freq;
var cmd="net.cmdQueues["+this.id+"].fireRequest()";
this.repeater=setInterval(cmd,freq*1000);
}
}
net.CommandQueue.prototype.unrepeat=function(){
if (this.repeater){
clearInterval(this.repeater);
}
this.repeater=null;
}

We’ve added quite a bit of new functionality here. Let’s step through it. First, we’ve introduced a global lookup of command queue objects b. This is a necessary evil given the limitations of the setInterval() method, which we’ll discuss shortly. The constructor takes a unique ID as an argument and registers itself with this lookup under this key.

The CommandQueue constructor now takes two other new arguments c. onUpdate is a Function object that is used to handle the tags that we introduced into our response XML. freq is a numerical value indicating the number of seconds between polling the server for updates. If it is set, then the constructor initializes a call to the repeat() function g, which uses JavaScript’s builtin setInterval() method to regularly execute a piece of code. setInterval() and its cousin setTimeout()accept only strings as arguments under Internet Explorer, so passing variable references directly into the code to be executed is not possible. We use the global lookup variable and the unique ID of this queue to develop a workaround to this problem in the repeat() method. We also keep a reference to the repeating interval, so that we can stop it using clearInterval() in our unrepeat() method h. In the fireRequest() method, we previously exited directly if the queue of commands to send was empty. That test has been modified now so that if an onUpdate handler is set, we will proceed anyway and send an empty queue in order to fetch any tags waiting for us. Alongside our own edited data, we send a timestamp telling the server the date that we last received updates d, so that it can work out to send us relevant updates. This is stored as a property of the command queue and set to 0 initially.
We pass these timestamps as UNIX-style dates, that is, the number of milliseconds elapsed since January 1, 1970. The choice of timestamp is based on portability.

If we chose a date format that was easier to read, we would run into issues with localization, differences in default formats across platforms and languages, and so on. Getting localization right is an important topic for Ajax applications, since the application will be exposed to users worldwide if it is on the public Internet or the WAN of a large organization. In the onload() function, we add the code required to update the last updated timestamp when a response comes in e and to parse tags f. The onUpdate handler function is called with the command queue as its context object and the tag DOM element as the sole argument.

In the case of our domain model of the solar system, the update handler function is shown in listing 6.2.

function updatePlanets(updateTag){
var attribs=updateTag.attributes;
var planetId=attribs.getNamedItem("planetId").value;
var planet=solarSystem.planets[planetId];
if (planet){
var fld=attribs.getNamedItem("fieldName").value;
var val=attribs.getNamedItem("value").value;
if (planet.fld){
planet[fld]=val;
}else{
alert('unknown planet attribute '+fld);
}
}else{
alert('unknown planet id '+planetId);
}
}

The attributes in the tag give us all the information that we need to update the domain model on the JavaScript tier. Of course, the data coming from the server may not be correct, and we need to take some action if it isn’t. In this case, we have fallen back on an alert() statement compounding the problems that were discussed in section 6.2.1.

We’ve added quite a bit more clever code to our command queue object in the process of handling updates from other users, including passing timestamps between the client and web tiers, and adding a pluggable update handler function.

Eventually we come full circle to the issue of informing the user of changes and asynchronous updates as they take place. In the next section, we look at our options for presenting this information to the user in a more workable fashion, and we’ll factor out that pesky alert() function.

6.3 Designing a notification system for Ajax

The alert() function that we’ve been relying on up to now is a primitive throwback to the earlier, much simpler days of JavaScript, when web pages were largely static and the amount of background activity was minimal. We can’t control its appearance in any way through CSS, and for production-grade notification, we’re much better off developing our own notification mechanisms using the techniques employed to build the rest of our Ajax user interface. This also provides a much greater degree of flexibility.

If we look across the full spectrum of computer systems, we see that notifications come in many shapes and sizes, varying considerably in their impact on the user. At the low end of the scale regarding obtrusiveness are changes to the mouse cursor (such as the Windows hourglass or the Mac “spinning beach ball”) or the addition of secondary icons or emblems to an image denoting the status of the files or other items in a folder. These simple indicators offer relatively little information.

A status bar can provide a bit more detail on background events, and finally the full-blown dialog can show a greater degree of detail than either. Figure 6.1 illustrates a range of notification conventions being used in the KDE desktop for UNIX. The folder called lost+found is not accessible to the current user, so a secondary image of a padlock has been superimposed over that folder. The status bar at the bottom of the main window gives further information on the contents of the folder being viewed, without interrupting the user. Finally, the error window that is presented when the user tries to open the locked folder presents a stronger notification requiring immediate action by the user. Compared to these notifications, the use of alert() is essentially ad hoc, as well as being simplistic and ugly. In our quest for robustness, consistency, and simplicity, it makes sense to develop a framework for presenting notifications to the user that we can reuse throughout our application. In the following sections we’ll do just that.
 Figure 6.1 Various conventions for providing status information in a user interface: modifying the icons to reflect particular characteristics (here access permissions), a status bar providing summary information, and a modal dialog. The interface shown here is the KDE desk top for UNIX workstations, but similar conventions are found in most popular graphical interfaces.

6.3.1 Modeling notifications
As a first step, let’s define what a notification message looks like. It contains a text description for the user and optionally an icon to display alongside the message. When we notify the user of background activity, some messages are going to be more urgent than others. Rather than working out each time whether or not to show a particular message, let’s define some generic priority levels, which we can then assign to each message.

In general, we want to tell the user something, which they can acknowledge and dismiss. Some messages might be important enough to stay around indefinitely until the user does dismiss them, whereas others will be relevant only for a limited time. Where a message does remove itself without user intervention, it may be in response to a callback, if it is telling the user that some background process such as a network download is under way and the process finishes before the user dismisses the notification. In other cases, such as a news feed, we may simply wish to assign a given lifetime to a message, after which it will tidy itself away. With these requirements in mind, listing 6.3 presents a Message object, which provides a generic behind-the-scenes representation of a notification that is to be presented to the user. Once we’ve established this model of notification messages, we can dress them up in various ways, as we will see later.

var msg=new Object();
msg.PRIORITY_LOW= { id:1, lifetime:30, icon:"img/msg_lo.png" };
msg.PRIORITY_DEFAULT={ id:2, lifetime:60, icon:"img/msg_def.png" };
msg.PRIORITY_HIGH= { id:3, lifetime:-1, icon:"img/msg_hi.png" };
msg.messages=new Array();
msg.Message=function(id,message,priority,lifetime,icon){
this.id=id;
msg.messages[id]=this;
this.message=message;
this.priority=(priority) ? priority : msg.PRIORITY_DEFAULT.id;
this.lifetime=(lifetime) ? lifetime : this.defaultLifetime();
this.icon=(icon) ? icon : this.defaultIcon();
if (this.lifetime>0){
this.fader=setTimeout(
"msg.messages['"+this.id+"'].clear()",
this.lifetime*1000
);
}
}
msg.Message.prototype.clear=function(){
msg.messages[this.id]=null;
}
msg.Message.prototype.defaultLifetime=function(){
if (this.priority<=msg.PRIORITY_LOW.id){
return msg.PRIORITY_LOW.lifetime;
}else if (this.priority==msg.PRIORITY_DEFAULT.id){
return msg.PRIORITY_DEFAULT.lifetime;
}else if (this.priority>=msg.PRIORITY_HIGH.id){
return msg.PRIORITY_HIGH.lifetime;
}
}
msg.Message.prototype.defaultIcon=function(){
if (this.priority<=msg.PRIORITY_LOW.id){
return msg.PRIORITY_LOW.icon;
}else if (this.priority==msg.PRIORITY_DEFAULT.id){
return msg.PRIORITY_DEFAULT.icon;
}else if (this.priority>=msg.PRIORITY_HIGH.id){
return msg.PRIORITY_HIGH.icon;
}
}

We define a global namespace object msg for our notification system, and within that an associative array from which any message can be looked up by a unique ID. The ID generation scheme will depend on the application using the framework.

We define three constants defining the three priority levels—low, default, and high—to which a message can be assigned. Each priority defines a default icon and lifetime (in seconds), both of which may be overridden by optional arguments in the constructor function. A lifetime value of -1, assigned to high-priority messages, indicates that the message will not expire automatically but will need to be dismissed explicitly, either by the user or by a callback function.

6.3.2 Defining user interface requirements
In MVC terms, we have provided a Model for our notification system here. To make it useful, we need to define a View. There are many possible ways of visually representing notifications. For this example, we have chosen to provide a status bar of sorts, upon which notifications are represented as icons, as illustrated in figure 6.2.
 
Figure 6.2 Status bar user interface for our notification system. Individual messages are represented by their icons. The red X icon is a standard icon provided for low-level notifications by our system.

The third message object on the status bar has provided its own icon, a blue, shaded sphere, which overrides the default X. Each notification that is added to this status bar can be inspected as a tooltip device, as shown in figure 6.3.
 
Figure 6.3 Messages on the status bar can be inspected by rolling the mouse over the icon, causing a tooltip to appear.

This mechanism is designed to be unobtrusive. The status bar occupies relatively little screen space, but it is apparent to the user when a new notification has arrived by the presence of an additional icon. For more urgent messages, we may  
Figure 6.4 Higher-priority messages are shown in a pop-up dialog, in which messages are listed in order of priority. wish for something more immediate. To this end, we will initially display only lowpriority messages in the status bar; default and high-priority messages will first appear in a pop-up dialog, as illustrated in figure 6.4, before being dismissed.

The dialog can be modal or nonmodal. In the case of modal dialogs, we use a semitransparent layer to block off the rest of the user interface until the user dismisses the dialog. When dismissed, the dialog is represented by an icon on the right side of the status bar. In the following two sections, we’ll look at implementations of these features.

关于我们  |  诚聘英才  |  联系我们  |  友情链接
版权所有:@ 智尚代写联盟 电话:0760-86388801 客服QQ:875870576
地址: 广东中山市学院路1号 皖ICP备12010335号-7
  • 論文作成開始報告書
  • 西语作业代写PLANIFICACI&
  • 西班牙语作业代写PLANIFICAC
  • 高等教育科学研究项目立项指南
  • Reason for applica
  • 日语学位论文开题报告代写
  • 翻译硕士(英语笔译及英语口译)学位论
  • 中国现当代文学翻译的现状与问题
  • 文学翻译新观念
  • 找人代写硕士论文,要求写手至少硕士学
  • 重复提取促进长期记忆保持和意义学习的
  • 艺术院校内容依托英语教学的实证研究
  • 基于概念场的认知框架中的概念隐喻分析
  • 多元回归统计建模在语料库语言学中近义
  • paper6工作室专注留学生论文代写
  • 德语医学论文标题汉译的编辑加工
  • 高职韩语专业毕业论文的问题分析
  • develop communicat
  • VICTORIA UNIVERSIT
  • 日本地址电话
  • 英语动词现在时与将来时呼应的认知解读
  • 核心素养与英语课堂教学
  • 新国标下商务英语精读内容与语言融合型
  • 语言生态学视阈下美国语言教育政策研究
  • 应用技术型民族院校的大学英语教学改革
  • 圣诞节西班牙语
  • 基于区域经济发展的分类递进式大学英语
  • MOOC对高校专业课教学的效能研究
  • 西班牙语论文代写
  • 实习报告写作要求规范细则
  • 茶本体的开发,实现和评估
  • Anaylse des Leben
  • um Material,was ge
  • TEXTOS WEB ACOCEX
  • praktische WurzelS
  • FAQ vom Würzelschn
  • 中国饮食文化法国饮食文化
  • 中国春节特色法国圣诞节
  • 英韩翻译案例
  • 中国自動車産業の現状と課題 -環境保
  • 战争的结构
  • 法语论文修改意见
  • reference 代写
  • A proposal submitt
  • Gründe der erfolge
  • 工业翻译中译英考试题目
  • Introduction to en
  • 从汉法主要颜色词汇的文化内涵看两国文
  • Un problème chez &
  • INTERNATIONAL AND
  • IHRM Individual re
  • НАЦИОНАЛЬНО-КУЛЬТУ
  • ТЕОРЕТИЧЕСКИЕ ОСНО
  • SPE会议论文翻译
  • Project Proposal 地
  • 中国意大利家用电器领域合作的可能性和
  • Career Goal与Career
  • Caractéristiques e
  • L'influence de l'S
  • 英语口语教学改革途径测试与分析
  • 语用学理论与高校英语阅读教学
  • 日本语研究计划书写作申请
  • To Whom it May Con
  • 译文中英对照葡萄酒产品介绍
  • 韩国传统用餐礼节
  • 日本語の暧昧語婉曲暧昧性省略表現以心
  • 研究计划书写作要求
  • Outline Impact of
  • 计算机工程与网络技术国际学术会议EI
  • 微软的人脸3D建模技术 Kinect
  • Qualitative resear
  • 新闻的感想
  • 与老师对话的测验
  • 韩语论文修改意见教授老师
  • 华南师范大学外国语言文化学院英语专业
  • APA论文写作格式
  • the surrounding en
  • Современное состоя
  • CHIN30005 Advanced
  • The APA Harvard Sy
  • Annotated Bibiolgr
  • Acker Merrall & Co
  • 资生堂进入中国市场的经营策略
  • Introduction to Pu
  • 软件测试Introduction t
  • Pro Ajax and java
  • 用户体验The user exper
  • AJAX Design Patter
  • The Rich Client Pl
  • Keyframer Chunks
  • 3D-Studio File For
  • Mathematics for Co
  • The Linux MTD, JFF
  • 中日体态语的表现形式及其差异
  • CB 202 System Anal
  • 论日本恐怖电影与好莱坞恐怖片的异同
  • 俄语论文修改
  • 古典诗歌翻译英语论文资料
  • <한중
  • 公司治理(Corporate Gov
  • 英语习语翻译中的移植与转换
  • 日语(上) 期末复习题
  • ACTIVIDAD CORRESPO
  • 리더&#
  • 购物小票翻译
  • 论文摘要翻译英文
  • Bedeutung der Prod
  • ELABORACIÓN
  • 英语考卷代写代做
  • 日本語の感情形容詞の使用特徴——ドラ
  • 未来創造学部卒業研究要領
  • 光之明(国际)低碳产品交易中心介绍
  • 中国の茶文化と日本茶道との比較—精神
  • 목차
  • Final Project Grad
  • 東京学芸大学>センターなど教員許 夏
  • 東京学芸大学 大学院教育学研究科(修
  • 白澤論
  • ポスト社会主義モンゴルにおけるカザフ
  • 言語と色彩現象—史的テクストをもとに
  • 渡来人伝説の研究
  • 中日企业文化差异的比较
  • Modellierung des B
  • 日本大学奖学金申请
  • 大学日语教师尉老师
  • 석사&#
  • Chemical Shift of
  • 中韩生日习俗文化比较
  • Measure of Attachm
  • 酒店韩国客人满意度影响因素研究
  • 要旨部分の訂正版をお送りします
  • Writing and textua
  • 日本企業文化が中国企業にもたらす啓示
  • 日本情报信息专业考试题
  • 雅丽姿毛绒时装有限公司网站文案(中文
  • 語用論の関連性理論「carston」
  • 組織行動と情報セキュリティ.レポート
  • Bedarf
  • 中日企业文化差异的比较
  • 从语形的角度对比中日“手”语义派生的
  • 中国明朝汉籍东传日本及其对日本文化的
  • 《中日茶道文化比较》
  • 从中日两国电视剧看中日文化之差异
  • FOM Hochschule für
  • Die Rolle der Bank
  • A Penny for Your T
  • 也谈ガ行鼻浊音的语音教学问题
  • On the Difference
  • 衣装は苗族の伝統文化の主な表現形式
  • 日语语言文学硕士论文:日本の义务教育
  • 日本的茶文化
  • Samsung Electronic
  • Synthesis and char
  • The traveling mark
  • The Japanese Democ
  • 四季の歌
  • CapitoloI La situa
  • The Effects of Aff
  • WEB服务安全保障分析
  • 音译汉语和英语的相互渗透引用
  • 中日两国服装贸易日语论文写作要求
  • 日语论文修改意见
  • 英语作文题目
  • 申请留学社会经验心得体会
  • BE951 Coursework O
  • Overview township
  • 日本の長寿社会考察
  • 日语老师教师电话联系方式
  • 「依頼」に対する中上級者の「断り」に
  • 日本語序論
  • component formatti
  • 日文文献资料的查阅方法
  • 日文文献资料的查阅方法
  • 日语文献检索日文文献搜索网站
  • 日本留学硕士及研究生的区别硕士申请条
  • Adult attachment s
  • レベルが向上する中国の日本学研究修士
  • 日本留学硕士(修士)与研究生的区别
  • Nontraditional Man
  • Engine Lathes
  • Automatic Screw M
  • Chain Drives
  • V-belt
  • Bestimmung der rut
  • 中山LED生产厂家企业黄页大全
  • 活用神话的文化背景来看韩国语教育方案
  • MLA論文格式
  • 旅游中介
  • MLA论文格式代写MLA论文
  • 小論文參考資料寫作格式範例(採APA
  • clothing model; fi
  • 共同利用者支援システムへのユーザー登
  • 太陽風を利用した次世代宇宙推進システ
  • RAO-SS:疎行列ソルバにおける実
  • 井伏鱒二の作品における小動物について
  • 從“老祖宗的典籍”到“現代科學的証
  • “A great Pecking D
  • 净月法师简历
  • 科技论文中日对照
  • 翻译的科技论文节选
  •  IPY-4へ向ける準備の進み具合
  • 論文誌のJ-STAGE投稿ʍ
  • Journal of Compute
  • 学会誌 (Journal of Co
  • 学会誌JCCJ特集号への投稿締切日の
  • 「化学レポート:現状と将来」
  • 韩语翻译个人简历
  • 九三会所
  • 事態情報附加連体節の中国語表現につい
  • International Bacc
  • HL introduction do
  • コーパスを利用した日本語の複合動詞の
  • 日语分词技术在日语教材开发中的应用构
  • 北極圏環境研究センター活動報告
  • 语用学在翻译中的运用
  • 日汉交替传译小议——从两篇口译试题谈
  • 総合科学専攻における卒業論文(ミニ卒
  • Heroes in August W
  • 玛雅文明-西班牙语论文
  • 西班牙语论文-西班牙旅游美食建筑
  • 八戸工業大学工学部環境建設工学科卒業
  • 親の連れ子として離島の旧家にやって来
  • 「米ソ協定」下の引揚げにおいて
  • タイトル:少子化対策の国際比較
  • メインタイトル:ここに入力。欧数字は
  • 東洋大学工学部環境建設学科卒業論文要
  • IPCar:自動車プローブ情報システ
  • Abrupt Climate Cha
  • Recognition of Eco
  • Complexities of Ch
  • Statistical Analys
  • Dangerous Level o
  • 中日对照新闻稿
  • 俄汉语外来词使用的主要领域对比分析
  • 两种形式的主谓一致
  • 韩语论文大纲修改
  • 중국&#
  • 俄语外来词的同化问题
  • 北海道方言中自发助动词らさる的用法与
  • 论高职英语教育基础性与实用性的有机结
  • 论高职幼师双语口语技能的培养
  • 论高职幼师英语口语技能的培养
  •     自分・この眼&
  • 成蹊大学大学院 経済経営研究科
  • アクア・マイクロ
  • 公共経営研究科修士論文(政策提言論文
  • 基于学习风格的英语学习多媒体课件包
  • 后殖民时期印度英语诗歌管窥
  • 汉语互动致使句的句法生成
  • 笔译价格
  • 携帯TV電話の活用
  • 英語学習におけるノートテイキング方略
  • 強化学習と決定木によるエージェント
  • エージェントの行動様式の学習法
  • 学習エージェントとは
  • 強化学習と決定木学習による汎用エージ
  • 講演概要の書き方
  • 对学生英语上下义语言知识与写作技能的
  • 英汉词汇文化内涵及其翻译
  • 论大学英语教学改革之建构主义理论指导
  • 国内影片片名翻译研究综观及现状
  • 平成13年度経済情報学科特殊研究
  • Comparison of curr
  • 英文论文任务书
  • This project is to
  • the comparison of
  • デジタルペンとRFIDタグを活用した
  • 無資格者無免許・対策関
  • 創刊の辞―医療社会学の通常科学化をめ
  • gastric cancer:ade
  • 揭示政治语篇蕴涵的意识形态
  • 试论专业英语课程项目化改革的可行性
  • 多媒体环境下的英语教学交际化
  • 翻译认知论
  • 读高桥多佳子的《相似形》
  • 以英若诚对“Death of A S
  • 论沈宝基的翻译理论与实践
  • 论语域与文学作品中人物会话的翻译
  • 浅析翻译活动中的文化失衡
  • 谈《傲慢与偏见》的语言艺术
  • 论语言结构差异对翻译实效性的影响
  • 英语传递小句的认知诠释
  • 英语阅读输入的四大误区
  • 在语言选择中构建社会身份
  • 私たちが見た、障害者雇用の今。
  • 震災復興の経済分析
  • 研究面からみた大学の生産性
  • 喫煙行動の経済分析
  • 起業の経済分析
  • 高圧力の科学と技術の最近の進歩
  • 「観光立国」の実現に向けて
  • 資源としてのマグロと日本の動向
  • 揚湯試験結果の概要温泉水の水質の概要
  • 計量史研究執筆要綱 
  • 日中友好中国大学生日本語科卒業論文
  • 제 7 장
  • 전자&
  • 現代國民論、現代皇室論
  • 記紀批判—官人述作論、天皇宗家論
  • 津田的中國觀與亞洲觀
  • 津田思想的形成
  • 反思台灣與中國的津田左右吉研究
  • 遠隔講義 e-learning
  • 和文タイトルは17ポイント,センタリ
  • Design And Impleme
  • Near-surface mount
  • 중국 &
  • 韩国泡菜文化和中国的咸菜文化
  • 무한&#
  • 수시 2
  • 韩流流向世界
  • 무설&#
  • 要想学好韩语首先得学好汉语
  • 사망&#
  • Expression and Bio
  • Increased Nuclear
  • 论女性主义翻译观
  • 健康食品の有効性
  • 日语的敬语表现与日本人的敬语意识
  • 日语拒否的特点及表达
  • Solve World’s Prob
  • 韩汉反身代词“??”和“自己”的对比
  • 韩汉量词句法语义功能对比
  • 浅析日语中的省略现象
  • 浅谈日语中片假名的应用
  • 土木学会論文集の完全版下印刷用和文原
  • 英语语调重音研究综述
  • 英汉语言结构的差异与翻译
  • 平等化政策の現状と課題
  • 日本陸軍航空史航空特攻
  • 商务日语专业毕业生毕业论文选题范围
  • 家庭内暴力の現象について
  • 敬语使用中的禁忌
  • Treatment of high
  • On product quality
  • Functional safety
  • TIDEBROOK MARITIME
  • 日文键盘的输入方法
  • 高职高专英语课堂中的提问策略
  • 对高校学生英语口语流利性和正确性的思
  • 二语习得中的文化错误分析及对策探讨
  • 高职英语专业阅读课堂教学氛围的优化对
  • 趣谈英语中的比喻
  • 浅析提高日语国际能力考试听力成绩的对
  • 外语语音偏误认知心理分析
  • 读格林童话《小精灵》有感
  • “新世纪”版高中英语新课教学导入方法
  • 初探大学英语口语测试模式与教学的实证
  • 中加大学生拒绝言语行为的实证研究
  • 目的论与翻译失误研究—珠海市旅游景点
  • 对学生英语上下义语言知识与写作技能的
  • 英语水平对非英语专业研究生语言学习策
  • 英语教学中的文化渗透
  • 中学教师自主学习角色的一项实证研究
  • 叶维廉后期比较文学思想和中诗英译的传
  • 钟玲中诗英译的传递研究和传递实践述评
  • 建构主义和高校德育
  • 论习语的词法地位
  • 广告英语中的修辞欣赏
  • 从奢侈品消费看王尔德及其唯美主义
  • 论隐喻的逆向性
  • 企盼和谐的两性关系——以劳伦斯小说《
  • 论高等教育大众化进程中的大学英语教学
  • 试论《三四郎》的三维世界
  • 李渔的小说批评与曲亭马琴的读本作品
  • 浅谈中国英语的表现特征及存在意义
  • 湖南常德农村中学英语教师师资发展状况
  • 海明威的《向瑞士致敬》和菲茨杰拉德
  • 围绕课文综合训练,培养学生的写作能力
  • 指称晦暗性现象透析
  • 西部地区中学生英语阅读习惯调查
  • 论隐喻的逆向性
  • 认知体验与翻译
  • 试析英诗汉译中的创造性
  • 言语交际中模糊语浅议
  • 认知体验与翻译
  • 关于翻译中的词汇空缺现象及翻译对策
  • 从互文性视角解读《红楼梦》两译本宗教
  • 从目的论看中英动物文化词喻体意象的翻
  • 高校英语语法教学的几点思考
  • 高校体艺类学生外语学习兴趣与动机的研
  • 大学英语自主学习存在的问题及“指导性
  • 从接受美学看文学翻译的纯语言观
  • 《红楼梦》两种英译本中服饰内容的翻译
  • 法语对英语的影响
  • 影响中美抱怨实施策略的情景因素分析
  • 代写需求表
  • 跨文化交际中称赞语的特点及语言表达模
  • 实现文化教育主导外语教育之研究
  • 试论读者变量对英语阅读的影响
  • 从文化的角度看英语词汇中的性别歧视现
  • 合作原则在外贸函电翻译中的运用
  • Default 词义探悉
  • 从图示理论看英汉翻译中的误译
  • 许国璋等外语界老前辈所接受的双语教学
  • “provide” 和 “suppl
  • 由英汉句法对比看长句翻译中的词序处理
  • 1000名富翁的13条致富秘诀中英对
  • 英语中18大激励人心的谚语中英对照
  • 反省女性自身 寻求两性和谐---评
  • 浅析翻译中的“信”
  • 集体迫害范式解读《阿里》
  • 横看成岭侧成峰-从美学批评角度解读《
  • 福柯的话语权及规范化理论解读《最蓝的
  • 播客技术在大学英语教学中的应用
  • 如何在山区中等专业学校英语课堂实施分
  • 奈达与格特翻译理论比较研究
  • 语篇内外的衔接与连贯
  • Economic globaliza
  • 用概念整合理论分析翻译中不同思维模式
  • 英语新闻语篇汉译过程中衔接手段的转换
  • 对易卜生戏剧创作转向的阐释
  • 动词GO语义延伸的认知研究
  • 反思型教师—我国外语教师发展的有效途
  • 输入与输出在词汇学习中的动态统一关系
  • 教育实践指导双方身份认同批判性分析
  • 中英商务文本翻译异化和归化的抉择理据
  • 从艺术结构看《呼啸山庄》
  • 从儒家术语“仁”的翻译论意义的播撒
  • 论隐喻与明喻的异同及其在教学中的启示
  • 话语标记语的语用信息在英汉学习型词典
  • 论森欧外的历史小说
  • 翻译认知论 ——翻译行为本质管窥
  • 中美语文教材设计思路的比较
  • 美国写作训练的特点及思考
  • UP语义伸延的认知视角
  • 成功的关键-The Key to S
  • 杨利伟-Yang Liwei
  • 武汉一个美丽的城市
  • 对儿童来说互联网是危险的?
  • 跨文化交际教学策略与法语教学
  • 试论专业英语课程项目化改革的可行性-
  • 论沈宝基的翻译理论与实践
  • 翻译认知论——翻译行为本质管窥
  • 母爱的虚像 ——读高桥多佳子的《相似
  • 浅析英语广告语言的特点
  • 中国の株価動向分析
  • 日语拒否的特点及表达
  • 日语的敬语表现与日本人的敬语意识
  • 浅析日语中的省略现象
  • 浅谈日语中片假名的应用
  • 浅谈日语敬语的运用法
  • 浅谈日语会话能力的提高
  • ^论日语中的年轻人用语
  • 敬语使用中的禁忌
  • 关于日语中的简略化表达
  • 关于日语的委婉表达
  • The Wonderful Stru
  • Of Love(论爱情)
  • SONY Computer/Notb
  • 从加拿大汉语教学现状看海外汉语教学
  • MLA格式简要规范
  • 浅析翻译类学生理解下的招聘广告
  • 日本大学排名
  • 虎头虎脑
  • 杰克逊涉嫌猥亵男童案首次庭审
  • Throughout his car
  • June 19,1997: Vict
  • 今天你睡了“美容觉”吗?
  • [双语]荷兰橙色统治看台 荷兰球员统
  • Father's Day(异趣父亲节
  • 百佳电影台词排行前25名
  • June 9,1983: Thatc
  • June 8, 1968: Robe
  • 60 players mark bi
  • June 6, 1984: Indi
  • 日本の専門家が漁業資源を警告するのは
  • オーストリア巴馬は模範的な公民に日本
  • 日本のメディアは朝鮮があるいは核実験
  • 世界のバレーボールの日本の32年の始
  • 日本の国債は滑り降りて、取引員と短い
  • 广州紧急“清剿”果子狸
  • 美国“勇气”号登陆火星
  • 第30届冰灯节哈尔滨开幕
  • 美国士兵成为时代周刊2003年度人物
  • BIRD flu fears hav
  • 中国チベット文化週間はマドリードで開
  • 中国チベット文化週間はマドリードで開
  • 中国の重陽の文化の発祥地──河南省西
  • シティバンク:日本の国債は中国の中央
  • イギリスは間もなく中国にブタ肉を輸出
  • 古いものと新しい中国センター姚明の失
  • 中国の陝西は旅行して推薦ӥ
  • 中国の電子は再度元手を割って中国の有