4 posts tagged “ajax”
I found a nice old web application I created a little less than a year ago during my Spanish class. The objective was simple, create a "wiki-esque" site that allows you to enter verbs, words and definitions and associate those with a picture. The idea was focused on being able to compose it as I was learning Spanish. At any rate:
The one feature I especially like about this site is the ability to add accents as you type in any text box.
Simply type the character of interest: a, then type the character ` (the backquote/tilda key on the top-left of the keyboard). This will immediately make any of the characters, accented. ?` = ¿, a` = á, n` = ñ... etc. Pretty neat eh?
Thanks to a leak from the WWDC, several details of the capabilities and limitations of the browser are now known, and major Ajax vendors are scrambling to make sure their toolkits will support it.
The resolution is 320×396 for the web viewing area in portrait mode. The dot pitch will be smaller than you’re used to, however, so you should avoid hard-coding font sizes.
Unfortunately, neither Java applets nor Flash will be supported in this browser, at least in the initial version. Video and audio is supported through Quicktime (H.264 baseline profile level 3.0). Interestingly, YouTube videos will work on the iPhone, but only because YouTube will recode their videos into H.264 format for the iPhone and Apple TV (instead of the On2 VP6 video format that they use now inside the Flash player). Since H.264 is one of the best high-tech formats available today, we might see better quality video at the same bandwidth. Links directly to movies will reportedly switch the iPhone into full-screen, landscape video playback.
The browser has some limitations most developers are not likely to run into, such as a 10MB max html size for the web page, 5 seconds of run time and 10MB heap allocation limits for Javascript, and a maximum of 8 documents viewed at once (in tabs).
The iPhone will have built-in support for viewing PDF, MS Word (.doc), and MS Excel (.xls) format files. PDF will likely work the best, since that’s a native format for MacOSX.
Telephone-specific urls will, for example, allow the user to click on a link and make a phone call. These include “sms:”, “tel:”, and “mailto:”. In some cases it appears special links are not really necessary. One source says that if a phone number appears anywhere on a web page Safari will automatically recognize it and make it clickable, just like browsers on some other phones.
Here are some more recommendations from Apple to make your content look its best on the iPhone:
- Separate HTML and CSS (that’s good advice all the time)
- Use well structured and valid HTML (ditto)
- Size images appropriately (don’t rely on browser scaling)
- Tile small images in backgrounds (don’t use large background images)
- iPhone supports both EDGE and Wi-Fi. EDGE pipe is smaller than Wi-Fi pipe, so consider bandwidth when developing.
- XHTML mobile documents supported.
- Stylesheet device width: 480px
- Apply different CSS for the iPhone. For example displaying a one column page for iPhone vs. a 3 column page on a desktop.
- There are no scroll bars or resize knobs. The iPhone will automatically expand the content.
- Avoid framesets. Scrollable frames are automatically expanded to fit the content
Bottom line:
Like the Opera-based internet browser on the Nintendo Wii, most developers will look at the iPhone as yet another high-volume consumer-oriented web platform for their pages and applications. As a first pass, it would be a good idea to ensure your apps don’t look like crap on the device. Then if you notice a lot of iPhone traffic or want to target it specifically for some other reason, you can use CSS and user agents to customize your presentation to your heart’s content.
Related info:
This is slightly outdated, but I figured I post about it anyways. If you didn't already see Bill appear on the many shows showing off Windows Vista, or see him in the tons of interviews by such sites as MSDN's Channel 9 or Channel 10. Then you might like watching this one of him on The Daily Show with Jon Stewart.
I'd like to say that in all of his interviews, you can definitely catch his aim on software of tomorrow. Where the software we produce and use becomes contextual and personalized. A great step in .NET, for instance, is such SDKs as WPF. Where the interaction of our applications is a lot less dull and a lot more productive and exciting for our users. Creating interactive and intuitive applications that only display what is needed and used in a given context. I see a lot of applications being developed that are based on this model of context + interaction + personalization.
Thinking of the many Web 2.0 Applications out there, I have seen less pushes towards desktop application development. Although, it is nice to have web applications that can store all my information and I can access it wherever I go, it can potentially open up a lot of security flaws where my data could be compromised.
Google Docs, and several other office applications now let you create documents and store them online. Even still we can do all of our finances, communications, and storage all online. Again, this can open the doors for hackers to steal almost anything we may possess given a little data mining. But this goes back to the old principle that I believe Matthew once told me: if you have extremely sensitive data, don't put it online. I'll agree in the sense that there is just information that we really don't want getting out such as our finances, but other data we may need it to be connected and viewed by others even if it is sensitive. This is where one of Bill Gates emails comes in handy. (Read it here)
I feel that the Web is a way of connecting people much more rapidly than a desktop application may. Utilizing community features, and other web application usage is a great idea for most applications. Integration is a very important role of development. There is of course, Smart Clients, where the application is already connected with the web. However, this will all, of course, depend on the application being built. The principles behind the application should determine how it is connected if at all.
Going back to the personalized context interaction, it may take nothing less than data mining to determine the users intent and basic needs to accomplish a given task. Whether or not a given task is difficult to accomplish will rely on how interactive it is. We are, of course, talking about complex applications and generally speaking web applications. Creating web applications that dynamically populate data, inserting ajax based controls with immutable data can be far more interactive than nearly all desktop applications. The basic problem with desktop applications is that most desktop apps are developed through static WYSIWYG editors, and thereby severally undermining the architecture of both the system and especially its interaction.
Along side the .NET 3.0 framework we have WYSIWYG editors that accomplish what I'm talking about in the Microsoft Expression Suite. One such is called Blend. In Blend, you design your application with all the interaction you would like, moving around controls, destroying them, creating them, manipulating them all through the editor. With most desktop application development cycles, this would take a lot of custom code. The Expression Suite definitely eases this process in development, making interaction/design stages of development a lot smoother into programming. The ability to create applications with truly intuitive interaction is becomming less and less difficult. I believe the next step in intuitive interaction is indeed context, providing relative information to the users. Some of the other concepts could also be vertical search and definitely personalization. We have already seen personalization spread through sites such as NetVibes and Pageflakes. It will interesting to see how this progresses into other fields of software development.
Dr. James McCaffrey has a very nice way to perform testing automation on Custom Ajax driven websites. The testing automation works really simply since everything is executed and logged via client-side javascript code.
The popularity of Web applications that use AJAX (Asynchronous
JavaScript And XML) technology has increased steadily over the past
year. When written correctly, AJAX can yield significant improvements
in performance and user experience compared with non-AJAX Web
applications. However, because AJAX Web applications work
asynchronously, traditional synchronous test automation techniques
generally don't work. In this month's column, I present a technique
that allows you to write lightweight test automation to verify the
functionality of AJAX Web applications.
More after the jump.
