SEO Tips & Tricks for flash websites

Usage of text in HTML

If you have only a very small amount of text in your Flash animation is to place that text in the <title> tag of the HTML page. Search engines weight page titles high.

Another solution is to put all the text “below the fold” so that although it is contained in the HTML page, the initial experience of visiting your page will be the effect of a bare page containing just the Flash animation.

If your site requires whole paragraphs of text, it is better to place it in the HTML, both from a search engine perspective and a user experience perspective. Keeping text in the HTML makes it easier for search engines to find the text and make sense of it. It also makes it easier for users to search through the text within the browser, print it, or copy and paste it.

Usage of links in HTML

Flash can be a great way to present complex navigation options to users using drop-down menus or other innovative controls. However, it can be difficult for web crawlers to find links when they are embedded only within the Flash animation. Simple solution to this is to make sure that any Flash navigation also appears somewhere on the page as links within the HTML. This can be done easily by putting links at the bottom or left side of a page. These standard practices are also helpful to the human visitors to your site, not just for search engine robots.

Provide a site index page your home page links to – This helps search engines navigate your site—whether or not you make heavy use of Flash. By doing so, human visitors can sense the layout and content of your site easily and web spiders definitely have an easier time hitting all the pages.

Another way to make sure search engines find all the pages in your site is to submit the page URLs directly to the search engines.

Use the Title and Description fields in Flash 8

The SWF file format in Flash 8 supports XMP metadata. The goal of this feature is to help address issues with search engine support for Flash. With this new feature, metadata can actually be output to any version of SWF, not just that generated by Flash 8. It is also a good idea to put this kind of information in your HTML, either in your page’s title and description metadata or in text within the page.

Use separate SWF files onto different web pages

Some websites built entirely in Flash use a single web page with a Flash animation embedded within it. When users interact with the site, new views are displayed within the Flash animation rather than by loading a new, discrete web page.

Although this can provide a great user experience visually and cause faster “page” loads, it has its drawbacks. For human visitors, it is impossible to bookmark a particular page because going back to that same link will take them to the beginning of the Flash experience. Similarly, it is impossible for search engines to understand each new state in the Flash experience as a different page and to link into that state.

Mobile Application Testing-Automation tools

          The mobile applications market experiences a drastic demand along with the growing technology in innovative world. So, every mobile application developed should be tested to make sure that it is bug free. Testing a mobile application will be done manually or by using automation tools similar to that of computer applications.

           Along with Manual Mobile Testing, presently many Mobile Automation Testing tools are evolving into the market. Some of the automation tools available to test Mobile Apps are provided below:

Robotium (Android): It helps to create powerful and robust automatic black-box test cases for Android applications.

W3C mobileOK Checker: It determines level of mobile-friendliness by performing various tests on a Web Page.

FoneMonkey (iPhone): This tool records all actions with the iPhone or iPad (while in use) and plays them back as a test script at any time. Through this, we can create, edit and playback the automation scripts that exercise an application’s user interface.

Eggplant (iPhone): It is a GUI automation testing tool for iPhone from TestPlant. It uses Image-Matching technology to test Graphical User Interface.

M-Eux: It allows us to automate, maintain and monitor the mobile test cases. It also identifies the GUI elements of the mobile device.

TestQuest Countdown: TestQuest Countdown consists of consists of 4 components like TestDesigner, TestManager, TestRunner and AssetManager used to develop, queue, run and share respectively.

Sikuli: IT uses visual technology to automate and test Graphical User Interfaces. It uses Sikuli Script, a visual scripting API for Jython, and Sikuli IDE, an integrated development environment for writing visual scripts with screenshots easily.

Deviceanywhere: It is used to test and monitor the functionality, usability, performance and availability of mobile apps and websites.

IBM Rational Performance Tester (RPT): It is an automated performance testing tool from IBM. Through this, a user can create tests, which transacts between an application client and server. During execution, it simulates a large transaction load on the server and collects server response times to identify the application bottlenecks.

Keynote MITE (Mobile Interactive Testing Environment): Using MITE, we can perform activities like:

• Browse – It enables us to interact and analyze the performance of the real time Web page.
• Verify – It will compare many aspects of the website against best practices and provide a comprehensive score for each page.
• Record – The mobile device simulator let us record scripts for all the actions performing while interacting with the website on the mobile device.
• Run – It runs the recorder scripts on any mobile device.
• Matrix Test – It automates testing by running one or more scripts on multiple devices concurrently.

Mobile Application Testing-Simulator versus Device testing

Simulators are mainly used for functional testing of basic flows. Simulators are not used for performance and usability testing, but the final testing is conducted on actual devices so crashes and hangings can be identified. One cannot get quality application while relying only on simulator. Device testing is necessary for all the applications, as with device testing we can understand the application behavior on different networks.

Simulator:

Is a software application that can accurately imitate a mobile phone. Simulator is mainly used by developers to check the functionalities implemented under development phase.

Let’s discuss the pros and cons of using simulators:

• Pros:

- Helps in isolating issues which are not volatile network connection dependent
- Provides a wide variety of testing over different types of device simulators for the same build
- Allows to test the same build in multiple device screens.

• Cons:

- Simulators of older generation handsets don’t resemble the device as closely
- Some issues which are hit by the speed at which input was given cannot be reproduced easily
- Hardware/Firmware environment variations detectable in device testing only
- Device testing is always preferred as it represents more likely end user scenarios.

Device: Is the actual handset where application installed and runs.

There are some pros and cons while using real devices for testing as well.

• Pros:

- Finds actual issues of application.
- Finds crashes, memory leak issues which can not found on simulators.
- Checks application over 2G and 3G and different networks
- Checks application behavior while incoming call, SMS, MMS and alarm.

• Cons:

- Expensive for compatibility testing of application over wide range of devices
- Consumes more time for adding excessive test data for testing purpose.

Mobile Application Testing- I Phone and Android applications testing

1.)   Testing mobile applications through
i) Devices.
ii) I phone — Simulator
iii) Android – Emulator

2.)   Installation & Uninstallation Testing

3.)   Few Security things if the application is a social networking application or links to a social networking applications like facebook, twitter and LinkedIn etc…

4.)   Inner functionality — Functional testing

5.)   System Crash / Force Close

6.)   Performance & Stress Testing

7.)   Page scrolling

8.)   Navigation to screens

9.)   Truncation errors

10.) Data Testing (Contents)

11.) Performance – application and inner pages load time

12.) Network Testing: (if the application is a Network based application)
i) Verify the behavior of application when there is Network problem and user is performing operations for data call.
ii) User should get proper error message like “Network error. Please try after some time”

13.) Application Specific Testing (ie Application behavior Testing based on the Mobile Device used)/ Some Device specific Testing for the Application

14.) Application Side Effects:
i) Make sure that your application is not causing other applications of device to hamper.
ii) Installed application should not cause other applications of device to hamper.

15.) Cosmetic issues (look and feel)

 

 

Application Level Hijacking…

The application level refers to obtaining session IDs to gain control of the HTTP user session as defined by the web application. In the application level, the session hijacker not only tries to hijack existing sessions, but also tries to create new sessions using stolen data. Session hijacking at the application level mainly involves obtaining a valid session ID by some means in order to gain control of an existing session or to create a new unauthorized session.

HTTP Session Hacking:

HTTP Session Hacking is all about obtaining the session ID. Since web application key off the value to determine identity.

Avoidance of Session Hacking:

To protect your network with session hijacking, a user has to implement both security measures at Application level and Network level. Network level hijacks can be prevented by ciphering the packets so that the hijacker cannot decipher the packet headers, to obtain any information which will aid in spoofing. Internet security protocol (IPSEC) has the ability to encrypt the packet on some shared key between the two parties involved in communication. IPSec runs in two modes: Transport and Tunnel. In Transport Mode only the data sent in the packet is encrypted while in Tunnel Mode both packet headers and data are encrypted, so it is more restrictive. To prevent your Application session to be hijacked it is recommended to use Strong Session ID’s so that they cannot be hijacked or deciphered at any cost. SSL (Secure Socket layer) and SSH (Secure site  Shell) also provides strong encryption using scripting to steal session information. SSL certificates so that session cannot be hijacked.

Conclusion:

Session hijacking remains a serious threat to networks and web applications on the web. It is important to protect our session data at both the network and application levels. Although implementing all of the countermeasures discussed here does not completely guarantee full immunity against session hijacking, it does raise the security bar and forces the session hijacker to come up with alternate and perhaps more complex methods of attack. It is a good idea to keep testing and monitoring our networks and applications to ensure that they will not be susceptible to the hijacker’s tricks.

TCP session hijacking methods

Now let us see briefly about the methods of TCP session hijacking

IP Spoofing

IP spoofing is a method used to gain unauthorized access to computers, where the messages send by the intruder to a computer with an IP address representing that the message is sent by a trusted host.

When the hijacker has successfully spoofed an IP address, he/she determines the next sequence number that the server expects and inject the forget packet with the same into the TCP session before the client can respond. Now “desynchronized state” is created.

The sequence and ACK numbers are no longer synchronized between client and server, because the server registers having received a new packet that the client never sent. Sending moreof these packets will create an even greater inconsistency between the two hosts.

Blind Hijacking

When the source routing is disabled, the session hacker can also employ blind hijacking where the user injects his malicious data into intercepted communications in the TCP session. Thus the word “blind” because the hijacker can send the data or commands, but cannot see the response. The hijacker basically guesses the responses of the client and server.

Man in the Middle attack (Packet sniffing)

This is a method which involves using a packet sniffer that intercepts the communication between the client and server. With all the data between the hosts flowing through the hijacker’s sniffer, he is free to modify the content of the packets. This technique is to get the packets to be routed through the hijacker’s host.

Two levels of Session Hijacking

Diagram of Session Hijacking Levels

Two levels of Session Hijacking – Explained

1.  Network Level – This type of hijacking involves TCP and UDP sessions.
2. Application Level – This type of hijacking occurs with HTTP sessions.

Though the attacks at each level are interrelated, most of the time, they will occur together depending on the attacked system. For example, a successful Network level attack on as TCP session will undoubtedly allow the hijacker to obtain the necessary information to make a direct attack on the user session on the application level.

1.     Network level hijacking

Network level session hijacking is particularly attractive to hackers, because they do not want to customize their attacks on a per web application basis. It is an attack on the dataflow of the protocol, shared across all web applications.

TCP Session hijacking

A TCP session hijacker creates a state where the client and server are unable to exchange data, so that he tries to forge acceptable packets for both ends, which acts as the real packets. Thus, attacker is able to gain control of the session. Wherein, the reason why the client and server drop packets sent between them is because the Server’s Sequence Number (SSN) no longer matches the Client’s Acknowledgement Number (ACK) and vice versa.

Widely used techniques for TCP session hijacking are as follows:

• IP Spoofing
• Blind Hijacking
• Man in the Middle attack (or) Packet Sniffing

UDP Session hijacking

This is the same as over TCP, except that UDP attackers do not have to worry about the overhead of managing sequence number and other TCP mechanisms. Injecting data into session without been detected is extremely easy in UDP as they are connectionless communications.

2.     Application level hijacking

The application level hijacking obtains session IDs to gain control of the HTTP user session as defined by the web application. In the application level, the session hijacker can also try to create new sessions using stolen data.

HTTP Session hijacking

HTTP session hijacking is all about obtaining the session ID, since web applications key off this value to determine identity.

Some common methods for these types of attacks are as follows:

• Obtain Session IDs
• Observation (Sniffing)
• Brute Force

Session Hijacking….

What are Sessions:

A session usually consists of a hash of values and a session id, usually a 32-character string to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way the browser will send it to the server on every request from the client.

Most applications need to keep track of certain state of a particular user. This could be the contents of a shopping basket or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

Session Hijacking:

Many web applications have an authentication system: a user provides a user name and password, the web application checks them and stores the corresponding user id in the session hash. From now on, the session is valid. On every request the application will load the user, identified by the user id in the session, without the need for new authentication. The session id in the cookie identifies the session.

Hence, the cookie serves as temporary authentication for the web application. Everyone who seizes a cookie from someone else, may use the web application as this user – with possibly severe consequences. Here are some ways to hijack a session, and their countermeasures:

-    Sniff the cookie in an insecure network. A wireless LAN can be an example of such a network. In an unencrypted wireless LAN it is especially easy to listen to the traffic of all connected clients. This is one more reason not to work from a coffee shop. For the web application builder this means to provide a secure connection over SSL.

-    Most people don’t clear out the cookies after working at a public terminal. So if the last user didn’t log out of a web application, you would be able to use it as this user. Provide the user with a log-out button in the web application, and make it prominent.

-    Many cross-site scripting (XSS) exploits aim at obtaining the user’s cookie.

Testing a Mobile Application

The ever increasing demand of mobile devices has given a push to software developers in taking the traditional web applications to mobile environment. The challenge is to provide user experience as similar and seamless across various mobile devices as possible in spite of the limitations which the mobile environment poses, adopting an agile methodology to develop the mobile applications for a diversified device environment, hardware and networking considerations.

Mobile device markets that includes Smart phones, Tablets, PDAs etc. is growing dynamically making the mobile application developers strive to deliver most robust, scalable applications with quality assurance Every device platform creates a unique testing environment challenging the mobile application developers to follow different testing strategies.

Checklist to follow while testing a mobile application:

Following is a basic checklist which is required while testing mobile application for any platform:

1.Installation & Uninstallation: To verify whether the application can be installed & uninstalled successfully.

2. Network Connectivity:

• The application can use simultaneous connections properly
• The application follows the GSM Offline profile correctly when making connections.
• When GSM Offline profile is selected, application cannot take network connection or send an SMS/MMS
• The application can utilize WLAN, 2G and 3G networks correctly.
• Performance of application during network connectivity problem.

3. Call/SMS/alarm handling: Verify that Application pauses and resumes for the same state when there is an incoming phone call/SMS/MMS/Alarm notification.

4. Check the look & feel of the application

5. Content: Check if enough information is displayed

6. The application must function as defined in the Help, user’s guide, or functional specification

7. Performance: Application and inner pages load time.

 

Mailer Checklist

We use the following Key points as a checklist to check the Mailers.

Check how the mailer appears when the images are blocked

• Make sure that the email design works with or without images turned on. Check whether the email is  sensible even when they are disabled.

Check whether Images are coded with their respective Alt Tags when the  images are turned off

• Instead of telling a user how to turn images on, check whether there is a copy which either describes the product being offered or that restates the key message.
• Look at the email when the images are turned off.  Check whether the alt tags serves as a alternative text for the reader.

Check how does the call-to-action work when images are blocked

• Are they invisible when images are disabled?
• Are your call-to-action text-based, using HTML fonts, colors, borders or backgrounds to make them pop? Calls-to-action built in this way are visible to all readers, even if graphics are disabled.
• Check the vital information’s like contact phone numbers or Web-site URLs are visible when images are disabled.
• Check whether you can read the company or newsletter name when images are turned off.
• Check the “click now” button or any other call-to-action with images blocked. How do they read?

Mailer width and size

• In general, standard email width is around 600 pixels. Keep the design within this width to avoid screen resolution issues.
• Check whether the Mailer size falls within 30kb.

Tested Quality

• Test your HTML and text versions across multiple email clients like Gmail, Yahoo, Rediff etc… focusing on the ones used by the majority of your subscribers.
• Proofread, check all links and confirm tracking functionality.
• Check whether the user has an alternative option to unsubscribe the mailer.