Ajax Based Google Translation Application

March 27, 2008

Another Ajax Based Google Translation Application Released


Recently, Google offered to the public their latest offering of language translation applications. Via public API, developers should be able to apply to their own website Google translates for developers to easily configure their website to any other languages they prefer. Aside from website add-on, developers can also use this API to build their custom designed gears which could be launched among the independently developed Google Gears. Adding this gear to their desktop, users should be able to type in simple commands for quick translation.


As of this writing, 13 languages are available and the number could be more in the following months. If your language is not on the list, maybe it is your chance to infuse the translation bot as part of the application. But if you are experienced in API and Gears development is not that extensive, you can use the API and apply it to your website.


We have indicated that this product is the latest of Google’s language applications. There are already a bunch of language related applications released by Google. Some of them could even translate Google Talk conversation on the spot. A language detection feature in Google’s IM was also released. You will then have the option of changing the language to your preferred tongue.


This added feature by Google is definitely a good thing. I am not sure if Google has the hidden agenda behind all these but I think the ability to understand another language fast online is a good application. But as a developer, there are concerns that are raised especially for end users.


First is the application security. Google has released an API for developers to build their own application and use it in any setting they prefer. There are of course developers who want nothing more than the advancement of communications. They steadily study this application so that others could enjoy the internet more.


However, as much as there are developers who are out there with good intentions. You can actually study the application and look for loopholes so that you can easily insert a script to update you with personal information. The latest API for language translation by Google is Ajax based which signals that another loophole is available for hackers to exploit. I may not be able to think of ways wherein really personal information could be used but as long as personal information could be accessed, this is always a security risk.


Another concern is speed. Even though this is an Ajax based application, launching this feature as Google Gear might be a little bit slower than expected. But this could be easily addressed when the API is stripped down to its bare essentials. It will not have any flashy interface but it will work well. You can still enjoy the power of language translation without being fancy.


Personally, this application might the best Google has made in the language translation application. But good things are coming from Google and as Ajax becomes more powerful, developers should be able to avail more API and source codes related to language translation.

Four Easy Steps for Ajax Development

Time and time again, developers are at awe on any Ajax based website. It’s complexity that matches its efficiency has made the developers and web owners to scramble for knowledge to develop this technique to this hottest web coding today. Although other codes have been thriving, none of them could be compared to JavaScript and the mark-up language XML – the main components of Ajax.


Fortunately, there are individuals who are already proficient in JavaScript long before it even become integrated to Ajax. Because of this, they were able to move ahead of figuring out how Ajax can be built in a simpler manner. Frameworks after frameworks have been released along with the battery of libraries that provide pre-built functions to developers. All the developers need to do is to change some things in the current library.


But that does not mean building an Ajax based website and application is easier in itself. Even with the framework, it is still complicated and could not be handled by any starting developer. 


On the other hand, if you are rearing to try your hands to develop an application in tune with today’s hottest development technique here are the simple steps in developing an Ajax based application:


Select the right framework – Let’s face it, you need a framework to build and application. Do not think that the set of libraries will diminish your creativity. There are already hundreds of frameworks out there and each of them has so many functions that most of them might not be even used. There are also frameworks that will help you develop an Ajax based application that do not even require knowledge of JavaScript. Personally, you might end up with a server side if you do not know JavaScript as most of the non-JavaScript frameworks are on that side.


Never overdo the framework – Keep it simple. There are so many functionalities out there and they might have “special considerations” especially for browser compatibility. There are lots of frameworks that could have cross browser so you will not have to stick to one framework and look for answers so that it could be compatible to different browsers. The libraries are already made so you just have to stick to the plane and customize only according to looks.


Not everything should be Ajaxed – Ajax is a very fascinating development technology but it does not have to be used in every part of the webpage. As of this writing, Google’s web crawlers for recognizing web content are not that optimized yet for Ajax. Leave some parts for HTML and meta-tags so that your website will somehow be recognized by web crawlers and be provided with the appropriate ranking.


Test your code – Never, never let your application go without testing it. As of today, there are applications that have been built to test Ajax based website. Some of it could come with a fee to ensure that the application works as planned.


These are only four steps to an Ajax based application. It stresses the importance of using a framework as this provides stability and reusability of the application. Use them and test the so that your application works as planned.

MOVING FROM HTML TO XHTML

March 10, 2008

HTML has progressed through a number of versions since its inception. The latest
standard is version 4.01, which was released by the W3C in late 1999. This is the last
release of HTML in its current state. The next generation of HTML is called the
Extensible Hypertext Markup Language (XHTML).The W3C released version 1.0

of XHTML in January 2000; a revised version was released in August 2002. As defined
in the W3C XHTML recommendation (www.w3.org/TR/xhtml1/), there are three
“flavors” of XHTML:

  • XHTML Strict—Use this when you want clean structural markup code, free
    of any markup tags associated with layout. Use XHTML Strict with
    Cascading Style Sheets to get the font, color, and layout effects you want. If
    you are beginning a new Web site, you should code to this recommendation.
  • XHTML Transitional—This type of XHTML is designed for people writing Web
    pages for the general public.The idea is to take advantage of XHTML features,
    including style sheets, but make small adjustments to your markup code for those
    viewing your pages with older browsers, which can’t understand style sheets.
  • XHTML Frameset—Use this when you want to use frames to partition the
    browser window into two or more sections.You can learn more about frames
    by reading the “Working with Frames” chapter on the Online Companion
    Web site for this book.

How do these three types of XHTML affect you as a Web developer? Your goal should
be to create code that matches the strict recommendation, using Cascading Style Sheets
for all of your display information. The benefit of the transitional type is that it allows
you to gradually migrate from existing HTML code that may still contain font and display
information to the more syntactically correct, cleaner markup code necessary to match
the strict type.

The frameset specification is important only if you plan to use frames to
partition the browser window, as described in the “Working with Frames” chapter posted
on the Online Companion Web site for this book.

The Limitations of HTML

HTML is a markup language, a structured language that lets you identify common
sections of a document such as headings, paragraphs, and lists. An HTML file includes
text and HTML markup (or element) tags that identify these sections. The HTML
markup tags indicate how the document sections appear in a browser. For example, the
<h1> element tags in the following code indicate that the text is a first-level heading:

<h1>WelcomeƒtoƒMyƒWebƒPage</h1>

The browser interprets the HTML markup elements and displays the results, hiding the
actual markup tags from the user. In the previous code, the user sees only the text
“Welcome to My Web Page” formatted as a level-one heading.

HTML adopts many features of SGML, including the cross-platform compatibility that
allows different computers to download and read the same file from the Web. Because
HTML is cross-platform compatible, it does not matter whether you are working on a
Windows PC, Macintosh, or UNIX computer.You can create HTML files and view
them on any computer platform.

HTML is not a What You See Is What You Get (WYSIWYG) layout tool. It was intended
only to express logical document structure, not formatting characteristics. Although
many current HTML editors let you work with a graphical interface, the underlying
code they create is basic HTML. However, because HTML was not designed as a layout
language, many editing programs create substandard code to accomplish a certain effect.

You cannot rely on the HTML editor’s WYSIWYG view to test your Web pages.
Because users can view the same HTML file with different browsers and on different
machines, the only way to be sure of what your audience sees is to preview your HTML
files in the browsers you anticipate your audience will use.

Despite its limitations, HTML is ideal for the Web because it is an open, nonproprietary
language that is cross-platform compatible. All of the markup tags are included with
every document and usually can be viewed through your browser. Once you are familiar
with the HTML syntax, you will find that one of the best ways to learn new coding
techniques is to find a Web page you like and view the source code. (You have a chance
to view the source code of a Web page in the Hands-on Projects at the end of this chapter.)

Ten Mistakes in Web Design

March 8, 2008

1. Bad Search
Overly literal search engines reduce usability in that they’re unable to handle typos, plurals, hyphens, and other variants of the query terms. Such search engines are particularly difficult for elderly users, but they hurt everybody.

A related problem is when search engines prioritize results purely on the basis of how many query terms they contain, rather than on each document’s importance. Much better if your search engine calls out "best bets" at the top of the list — especially for important queries, such as the names of your products.

Search is the user’s lifeline when navigation fails. Even though advanced search can sometimes help, simple search usually works best, and search should be presented as a simple box, since that’s what users are looking for.

2. PDF Files for Online Reading
Users hate coming across a PDF file while browsing, because it breaks their flow. Even simple things like printing or saving documents are difficult because standard browser commands don’t work. Layouts are often optimized for a sheet of paper, which rarely matches the size of the user’s browser window. Bye-bye smooth scrolling. Hello tiny fonts.

Worst of all, PDF is an undifferentiated blob of content that’s hard to navigate.

PDF is great for printing and for distributing manuals and other big documents that need to be printed. Reserve it for this purpose and convert any information that needs to be browsed or read on the screen into real web pages.

> Detailed discussion of why PDF is bad for online reading

3. Not Changing the Color of Visited Links
A good grasp of past navigation helps you understand your current location, since it’s the culmination of your journey. Knowing your past and present locations in turn makes it easier to decide where to go next. Links are a key factor in this navigation process. Users can exclude links that proved fruitless in their earlier visits. Conversely, they might revisit links they found helpful in the past.

Most important, knowing which pages they’ve already visited frees users from unintentionally revisiting the same pages over and over again.

These benefits only accrue under one important assumption: that users can tell the difference between visited and unvisited links because the site shows them in different colors. When visited links don’t change color, users exhibit more navigational disorientation in usability testing and unintentionally revisit the same pages repeatedly.

> Usability implications of changing link colors
> Guidelines for showing links Cartoon - guy being crushed under wordy ‘terms and conditions’ legalese

4. Non-Scannable Text
A wall of text is deadly for an interactive experience. Intimidating. Boring. Painful to read.

Write for online, not print. To draw users into the text and support scannability, use well-documented tricks:

    * subheads
    * bulleted lists
    * highlighted keywords
    * short paragraphs
    * the inverted pyramid
    * a simple writing style, and
    * de-fluffed language devoid of marketese.

> Eyetracking of reading patterns

5. Fixed Font Size
CSS style sheets unfortunately give websites the power to disable a Web browser’s "change font size" button and specify a fixed font size. About 95% of the time, this fixed size is tiny, reducing readability significantly for most people over the age of 40.

Respect the user’s preferences and let them resize text as needed. Also, specify font sizes in relative terms — not as an absolute number of pixels.

6. Page Titles With Low Search Engine Visibility
Search is the most important way users discover websites. Search is also one of the most important ways users find their way around individual websites. The humble page title is your main tool to attract new visitors from search listings and to help your existing users to locate the specific pages that they need.

The page title is contained within the HTML <title> tag and is almost always used as the clickable headline for listings on search engine result pages (SERP). Search engines typically show the first 66 characters or so of the title, so it’s truly microcontent.

Page titles are also used as the default entry in the Favorites when users bookmark a site. For your homepage, begin the with the company name, followed by a brief description of the site. Don’t start with words like "The" or "Welcome to" unless you want to be alphabetized under "T" or "W."

For other pages than the homepage, start the title with a few of the most salient information-carrying words that describe the specifics of what users will find on that page. Since the page title is used as the window title in the browser, it’s also used as the label for that window in the taskbar under Windows, meaning that advanced users will move between multiple windows under the guidance of the first one or two words of each page title. If all your page titles start with the same words, you have severely reduced usability for your multi-windowing users.

Taglines on homepages are a related subject: they also need to be short and quickly communicate the purpose of the site.

7. Anything That Looks Like an Advertisement
Selective attention is very powerful, and Web users have learned to stop paying attention to any ads that get in the way of their goal-driven navigation. (The main exception being text-only search-engine ads.)

Unfortunately, users also ignore legitimate design elements that look like prevalent forms of advertising. After all, when you ignore something, you don’t study it in detail to find out what it is.

Therefore, it is best to avoid any designs that look like advertisements. The exact implications of this guideline will vary with new forms of ads; currently follow these rules:

    * banner blindness means that users never fixate their eyes on anything that looks like a banner ad due to shape or position on the page
    * animation avoidance makes users ignore areas with blinking or flashing text or other aggressive animations
    * pop-up purges mean that users close pop-up windoids before they have even fully rendered; sometimes with great viciousness (a sort of getting-back-at-GeoCities triumph).

8. Violating Design Conventions
Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to worry about what will happen. Instead, they know what will happen based on earlier experience. Every time you release an apple over Sir Isaac Newton, it will drop on his head. That’s good.

The more users’ expectations prove right, the more they will feel in control of the system and the more they will like it. And the more the system breaks users’ expectations, the more they will feel insecure. Oops, maybe if I let go of this apple, it will turn into a tomato and jump a mile into the sky.

Jakob’s Law of the Web User Experience states that "users spend most of their time on other websites."

This means that they form their expectations for your site based on what’s commonly done on most other sites. If you deviate, your site will be harder to use and users will leave.

9. Opening New Browser Windows
Opening up new browser windows is like a vacuum cleaner sales person who starts a visit by emptying an ash tray on the customer’s carpet. Don’t pollute my screen with any more windows, thanks (particularly since current operating systems have miserable window management).

Designers open new browser windows on the theory that it keeps users on their site. But even disregarding the user-hostile message implied in taking over the user’s machine, the strategy is self-defeating since it disables the Back button which is the normal way users return to previous sites. Users often don’t notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill up the screen. So a user who tries to return to the origin will be confused by a grayed out Back button.

Links that don’t behave as expected undermine users’ understanding of their own system. A link should be a simple hypertext reference that replaces the current page with new content. Users hate unwarranted pop-up windows. When they want the destination to appear in a new page, they can use their browser’s "open in new window" command — assuming, of course, that the link is not a piece of code that interferes with the browser’s standard behavior. Cartoon - woman (at car dealership): ‘How much is it with automatic transmission?’ - sleazy salesman: ‘I’ll give you a hint - it’s an EVEN number…’

10. Not Answering Users’ Questions
Users are highly goal-driven on the Web. They visit sites because there’s something they want to accomplish — maybe even buy your product. The ultimate failure of a website is to fail to provide the information users are looking for.

Sometimes the answer is simply not there and you lose the sale because users have to assume that your product or service doesn’t meet their needs if you don’t tell them the specifics. Other times the specifics are buried under a thick layer of marketese and bland slogans. Since users don’t have time to read everything, such hidden info might almost as well not be there.

The worst example of not answering users’ questions is to avoid listing the price of products and services. No B2C ecommerce site would make this mistake, but it’s rife in B2B, where most "enterprise solutions" are presented so that you can’t tell whether they are suited for 100 people or 100,000 people. Price is the most specific piece of info customers use to understand the nature of an offering, and not providing it makes people feel lost and reduces their understanding of a product line. We have miles of videotape of users asking "Where’s the price?" while tearing their hair out.

Even B2C sites often make the associated mistake of forgetting prices in product lists, such as category pages or search results. Knowing the price is key in both situations; it lets users differentiate among products and click through to the most relevant ones.

Get free blog up and running in minutes with Blogsome | Theme designs available here