Category Archives: web authoring

image

Telerik releases Kendo UI components for ASP.NET MVC

Component vendor Telerik has released an updated version of Kendo UI, its HTML5 framework. This is the first non-beta release with support for ASP.NET MVC server wrappers, with components including Grid, ListView, calendar and date controls, tree view, menu, editor and more. Kendo UI supports the MVVM (Model View ViewModel) pattern popular with Microsoft developers.

image

 

Telerik seems to be treading a careful path, maintaining its strong links to the .NET developer community while also creating a framework that can be used on other platforms.

I spoke to Todd Anglin, VP of HTML5 tools. Why the support for ASP.NET MVC – is Telerik seeing this becoming more popular than Web Forms, the older ASP.NET approach to web applications?

“Something in the range of 70% of ASP.NET developers are on web forms. We do see a bit of a trend that as they start new projects, developers are adopting ASP.NET MVC and HTML5, which is where it makes sense to use Kendo UI,” he told me.

The main reason though is that Kendo UI is less suitable for Web Forms, where more of the client-side code is generated by the framework. “Web Forms are a very high level abstraction,” said Anglin. “With MVC developers are a little closer to the metal.”

That said, he is not ruling out a Web Form wrapper for Kendo UI long-term.

Anglin says Kendo UI’s use of JQuery is a distinctive feature.  “Over the last few years JQuery has clearly risen above the pack to be the most common core Javascript library and the one most developers are familiar with. Unlike most commercial libraries out there Kendo UI chooses the JQuery core as the starting point and builds on that, so developers that adopt Kendo UI have a smoother on-ramp.”

Kendo UI supports both mobile and desktop web applications, but with different controls. “We believe that developers should offer experiences that are tailored to each device class, which is why you have Kendo UI web for keyboard and mouse, and Kendo UI mobile with a mobile-specific interface. We share code behind that, like the data source, between web and mobile, but we don’t think the interface on a mobile device should be the same as you show on a desktop browser,” said Anglin.

What about the tools side? Although Anglin says “We want to be agnostic on tools”, there is particularly good support for Visual Studion. “Kendo UI integrates with anything that supports HTML and JavaScript well, which includes the latest version of Visual Studio. We are delivering full vsdoc support for Visual Studio so that developers in that environment get Intellisense for JavaScript. But if you’re on a Mac you can use other tools,” he told me.

More interesting is a forthcoming cloud IDE. “We’ve just revealed a new tool called Icenium which is a cloud-based development environment for creating apps in HTML and JavaScript. It’s an incredible environment for building apps with Kendo UI.”

How about HTML5 apps that target the Windows Runtime (Metro) in Windows 8 – will Kendo UI work there? Apparently not:

“It’s certainly something we’ve paid attention to. Telerik’s primary position for Windows 8 runtime and Windows 8 development is with the traditional .NET targeted tools. Our RAD tools later this year will focus on introducing XAML and HTML tools for Windows Runtime. The HTML tools that we introduce will have a shared engineering core with Kendo UI, but we’ll make a tool that is specifically targeted at that runtime.

“Kendo UI is really focused on the cross-platform, cross-browser experience. You write once, at a core code level, and then use all the runtimes out there for HTML and JavaScript. Whereas Windows Runtime is leveraging familiar technology in HTML and JavaScript, but when you write a Windows Runtime app you are writing Windows software. It’s very platform-specific.”

Book Review: Smashing UX Design (a great read for developers too)

That the abbreviation UX can appear in a book title without expansion says a lot about the extent to which user-focused design is now embedded in the web development industry. The theory behind it is that User Experience is primary when designing a web site. The word "experience" suggests that this is not just about usability, or attractiveness, or performance, or enjoyment, but rather about all those things and how they combine when the end user is navigating your site.

image

This book is for professional designers who want techniques for putting UX design into practice. The authors, Jesmond Allen and James Chudley, work for UX consultancy Cxpartners, based in Bristol in the UK, and the book is written from their perspective, including tips on how to work with your clients. That said, this is an excellent read even if you do not fall into that niche, thanks to the expertise and professionalism which informs the content.

There is a note right at the start of the book about the interaction between development and design teams which seems to me of key importance:

In order to produce designs that development teams can utilize, it is helpful for UXers to understand the development process they will be using. As external consultants, we do not always have the opportunity to work with development teams on a daily basis as they create a functional product from our designs, although we always strive to make ourselves available to developers as they work. Internal UX staff will likely have a much closer relationship with their development teams.

Some developers may see UX activities as troublesome big design up front. However, UX activities contribute to requirements gathering and backlog prioritization activities. These activities typically take place long before development sprints begin.

In order to produce robust products, it is important that UX research and design activities take place throughout the design and build cycle, whether it is product managers, UXers, or developers who perform the activities.

The emphasis is mine. A bad scenario, for example, runs like this. The project is initiated and handed to a design team, who come back with good-looking sketches and mock-ups. The developers then implement the design, but discover that it does not quite work as-is, maybe because the designers did not appreciate every nuance of the workflow, or because of evolving new requirements, or performance problems, or any number of other issues.

At this point the developers may endeavour to match the not-quite-working design as closely as possible, blaming shortcomings on the “bad design”. Or they may adapt the design to work better technically, potentially wrecking the design concept and delivering something which users will perceive as odd. This scenario is more likely to occur when budgets are particularly constrained and the design team external.

Note that Agile methodology has always emphasized that the team is the whole team – stakeholders, developers, designers, users, everyone – so it makes sense to keep designers involved right through the process. Put another way, do not allocate a design budget and spend it all up-front, before development begins.

It all comes down to communication, respect and understanding between team members, which is why this book is one that developers as well as designers should read.

Be clear: this is not a book about technology, so look elsewhere (perhaps to one of the other Smashing titles) if you want help with making beautiful web pages using CSS, or a how-to guide for building web sites. Smashing UX Design is about the process rather than the outcome, though there are plenty of practical tips along the way.

The book is in four parts. Part one is a general introduction to the concepts behind UX design and planning UX projects. Part two covers tools and techniques for UX research and evaluation, such as running requirements workshops, usability tests, surveys, analytics, and expert reviews.

The third part is about tools and techniques for UX design. If you are wondering what an Ideation Workshop is, you will find out how to run one here. Another technique described is how to create a "user persona", a fictional user who represents a category of users. There is also a discussion of wireframes, sketches and prototypes.

Finally, the fourth part looks in more detail at UX design for specific site pages, including the home page, search, product pages, shopping carts, images and tables. This is the section of most general interest, being full of practical suggestions and thought-provoking comments on what makes web pages work well for the user.

There is a too-brief chapter on mobile UX and this is a weakness of the book: not much on how tablets and smartphones are impacting UX design.

If you run or plan to run a web design business, then the book is perfect. It is also a great read for professional web developers. Individuals who are doing their own web design, or just want to understand it better, will find good content here but also a rather jargon-heavy style and probably more information than they need about working with clients and running workshops of various kinds.

 

Appcelerator Titanium gets Mobile Web SDK, cloud services

Appcelerator’s Titanium cross-platform development framework has moved up a gear with the announcement of two new features:

  • A set of cloud services, based on those acquired with Cocoafish in February this year. These are now known as Appcelerator Cloud Services (ACS).
  • Support for mobile web applications as well as native

These features are integrated into the Titanium development environment, an Eclipse-based IDE which has evolved from Aptana, a JavaScript tool acquired in early 2011. Start a new project, and ACS support is included by default.

image

The cloud services are hosted on Amazon and comprise the following:

  • Push Notifications
  • User management
  • Photo manipulation and storage
  • Places (rich location storage)
  • Social integration
  • File Storage
  • Check-ins
  • Status updates
  • Chats
  • Friend connections
  • Ratings and Reviews
  • Discussion forums
  • Event planning
  • Messaging
  • Key-Value data storage

“We have a portfolio of additional services rolling out over the next several quarters,” said Jo Ann Buckner, VP of Product Management. There are code examples here. A limited usage of the services is available free, after which it is pay as you go. It is a REST API that you can use from any platform; use of Titanium is not essential.

The other big feature is the Mobile Web SDK. Why is Appcelerator doing this given that it has been pushing native code apps as the way forward for mobile deployment?

“Two reasons,” says Buckner. “The debate has been going on for a long time, is it native, or web? Our position is that it native and mobile web are complementary. We have customers building native apps with Titanium that also want to have a mobile web presence, even for iOS and Android. Some customers will just interact with a mobile web site and never download the application.

“The second is reach beyond iOS and Android.”

Does that mean Appcelerator will not support other platforms such as Blackberry or Windows Phone with its native approach? “This is not a replacement for those efforts. We are investing in support for additional platforms,” says Buckner.

There are differences of course between what you can do in a native app, and what you can do in a web app, and these differences vary according to the target browser. Titanium allows you to write platform-specific code in order to workaround these problems, or to vary the user interface to suit the device. The illustration below shows the new Titanium IDE with an app which targets both Android and the Mobile Web, and you can see the folders on the left which separate common code and platform-specific code (click the image to enlarge).

image

Titanium installs its own web server for testing. Here is an example running in the Android emulator, served from Titanium.

image

When should you do a native app and when a mobile web app? “You’re going to build more than one application,” says Mike King, Appcelerator’s Principal Mobile Strategist. “If you are doing an augmented reality application the native interaction is going to require that to be a native application. You can do a forms-based application as well, and mobile web is going to be a better fit for that. Different use cases require different architectures.”

But why do your mobile web apps in Titanium, when you could use pure HTML 5 tools instead? “It’s about one platform for all of your development requirements, as opposed to one for native and one for HTML 5,” says King.

Titanium is certainly evolving with impressive speed. The latest 2.0.1 IDE is a rich tool, and pop-up help guides you concerning supported platforms for each keyword.

image

Another strong point is the way you can easily write conditional code for tablet form-factors.

The comparison with Adobe PhoneGap is interesting. PhoneGap takes a different approach, supporting native apps but by means of the embedded browser in each device, rather than by building a native user interface. Titanium’s new mobile web support is different in that it runs as a web app in the browser, not as a native app with an embedded browser.

Sold out QCon kicks off in London: big data, mobile, cloud, HTML 5

QCon London has just started in London, and I’m interested to see that it is both bigger than last year and also sold out. I should not be surprised, because it is usually the best conference I attend all year, being vendor-neutral (though with an Agile bias), wide-ranging and always thought-provoking.

image

A few more observations. One reason I attend is to watch industry trends, which are meaningful here because the agenda is driven by what currently concerns developers and software architects. Interesting then to see an entire track on cross-platform mobile, though one that is largely focused on HTML 5. In fact, mobile and cloud between them dominate here, with other tracks covering cloud architecture, big data, highly available systems, platform as a service, HTML 5 and JavaScript and more.

I also noticed that Abobe’s Christophe Coenraets is here this year as he was in 2011 – only this year he is talking not about Flex or AIR, but HTML, JavaScript and PhoneGap.

Financial Times thrives on HTML 5, paywall, and snubbing Apple iTunes

I spoke to Rob Grimshaw, Managing Director of FT.Com, shortly after Mobile World Congress in Barcelona, where the FT web app won an award for “Best Mobile Innovation for Publishing”.

image

I was interested in speaking to Grimshaw for two reasons.

First, the FT is a publication which has successfully managed the transition from print to online. The latest published results , for the first half of 2011, report that FT Group sales were up 7% and profits up 10%, “enhanced by digital subscriptions.”

Second, the FT took the initiative to bypass Apple’s app store with its onerous subscription terms by remaking its app as HTML5, as reported here .
The award “was the icing on the cake for the whole process,” Grimshaw told me. “When we abandoned the native app and stepped out of iTunes, it was a big commercial gamble, and it was a rueful moment as well because we’d created a beautiful native app and won an Apple design award.”

Was the FT move all about subscription fees, or were there other factors? “It was not all about Apple,” said Grimshaw. “Certainly their 30% tax on subscriptions didn’t make sense to us, because we already have our own platform so why pay somebody else to use their platform? Second, they would have owned the relationship with the customer. That’s important for various reasons, but for example it makes it difficult to manage churn, which is a crucial aspect of a subscription business.

“There were some other reasons. The mobile market would have been problematic if we had to keep developing all our applications for many different  operating systems. The overhead is enormous. It doesn’t stop once you’ve launched the app, you have to keep ugrading and changing.

“HTML 5 offers a way out of that headache by producing code that runs across multiple platforms.

“When you add all of that together, it seems to be smart to go the HTML 5 route even though it was technologically risky because at the time nobody else had done it.”

So what has been the impact of the web app versus the native app?

“A lot of people said, if we leave iTunes we’ll disappear from the world. We haven’t found that to be the case. In the four month period after we launched the web app, from June through to October 2011, our traffic on the iPad and the iPhone increased by over 50%. 1.7 million people have now visited the web application, more than ever downloaded our old iPhone and iPad app combined.

“We have many tools and techniques which help us to promote and build audience in the browser, and they work just as effectively for the web app as they do for our normal web sites.”

Is the success of the web app a reflection of the type of app, which is content-dominated, or will web apps dominate more generally in the mobile space?

“I think that HTML 5 will dominate. The buzz around HTML 5 at Mobile World Congress reinforced that view. It feels to me that there is an unstoppable momentum behind it,” said Grimshaw, mentioning PhoneGap-style native wrappers as well as pure web apps. “The counter argument is that for some of the new features of phones and tablets you have to use native code. However, I think 90% of applications don’t need that kind of support. We produce a very sophisticated app, and HTML 5 covers all the functions that we would ever need to use.”

“Once people discover what they can do within the browser they will start thinking why would you develop in native when it creates all of these headaches.”

As form factors become more varied, do you see a convergence between what you do for mobile and what you do for the wider internet?

“I can see them coming together. I can imagine a day where a single set of HTML 5 code can power our site across the full range of smartphones, tablets and desktop. The only obstacle is that so many browsers on the desktop don’t support HTML 5 fully.

“That doesn’t make all the contexting go away. Now with our mobile development we are dividing screen sizes into four buckets, and the thinking is that we will have to design for those four screen sizes. Device manufacturers are going to carry on producing a device to occupy every possible niche, and as publishers we have to cope with that.”

How important is cloud and mobile to your business, what new opportunities does it offer?

“Mobile is incredibly strategically important. I’m personally convinced that mobile will be the main distribution channel for news in the future. People’s lives don’t stop when they leave their desks or exit their houses. They want to carry on their friendships, their business, their reading. If you have a powerful mobile device that can deliver that, you’re going to gravitate to that device, and pretty soon it does become the main channel.

“We already see the audience migrating onto mobile. About 20% of our page views now come from mobile devices. That could be over half within three years. Figuring out how to present our content, sell our subscriptions, deliver our advertising on mobile devices is hugely important.

“It’s a shift on a tectonic scale. For publishers this is a bigger shift than the shift from print to desktop, and it’s happening faster.

“It does create new opportunities as well. We have a new sales channel, we’re now selling our subscriptions through mobile devices. 15 to 20% of our new digital subscriptions every week are sold directly through mobile devices.

“It gives us the potential to reach new audiences. We’ve seen some good evidence from the mobile operators to show that our audience from mobile is much younger that our audience on desktop or on print. Devices are helping us to reach younger audiences and recruit readers who might be with us for the rest of their lives.”

What about social media and the relationship with the big web portals, Google, Facebook, Twitter?

“I see social media as a parallel trend to mobile. Mobile is the desire of people to take content with them physically. Social media is about the desire of people to take content with them virtually, and equally powerful.

“On the advertising side I find social media a little alarming because of scale. Facebook has a trillion page views a month, which makes them 400 times bigger than the BBC and 1500 times bigger than the New York Times. It’s scale which is unimaginable for most publishers, and they have tremendous insight into their audience. That’s a potent cocktail. And every time someone shares an FT article on Facebook, an extra bit of data builds up on their side that tells them about our readers.

“On the subscription side though it is all positive and they can be powerful sales channels for us. We have big communities in social media, 300,000 odd on Facebook, 1.2 million Twitter followers, and these are to some extend self-selecting marketing audiences, people who stuck up their hand and said we’re interested in the FT.

“We also believe we can find ways to allow people to consume content in the social media environment if they are subscribers. We’re working on finding ways to do that.”

What do you think of paywalls versus free content for newspapers on the web? Does the paywall only work because the FT is a niche publication, albeit a large niche?

“We are very much on the paywall side and unashamedly so, we think our content has tremendous value and people do not object to paying for it. We now have 270,000 digital subscribers and that compares to our newspaper circulation which is around 330,000, so we’ve been successful in building up a paying audience in digital which is now pretty close in scale to our paying audience. It’s been an enormously success business venture for us.

“When you look at the publishers that are giving all their content away, the reason they are giving it all away is in order to build up a bigger audience for advertising. But the scale of the competition in the advertising market is so huge that actually it is a fruitless exercise, unless you can acquire a scale which will give you billions of page views a month. It’s very hard to see how you can build a decent business just from online advertising. The numbers don’t stack up.

“My message to other publishers is not necessarily that you have got to have a paywall, but is that you probably need other ways to make money, other than online advertising.”

WebKit dominance threatens mobile web standards – but who will care?

Daniel Glazman, co-chairman of the W3C CSS working group, has written a strongly-worded post describing how the “over-dominance” of the WebKit rendering engine threatens web standards.

Everyone loves the open source WebKit, so how is this so? The issue is a complex one. Those who make web browsers do not want to be tied only to those standards already ratified by the W3C as part of HTML or CSS. Therefore, they add features, sometimes in the hope that they will become standards, but use a vendor-specific prefix such as -webkit-,-moz- or -ms-. If you use those features in your markup, you do so in the awareness that they will only work on that specific vendor’s browser. The idea is that the best vendor-specific extensions become standard, in which case the prefix is dropped; or are replaced by an equivalent standard, in which case the prefix is also dropped. This has become an accepted part of the way standards are formed.

The issue now is that WebKit dominates the mobile web to the extent that web authors can assume its use without losing many users. WebKit is used in Apple iOS, Google Android, RIM BlackBerry 6 and higher, as well as on the desktop in Apple Safari and Google Chrome. Amazon also uses WebKit in the Kindle and of course the Android-based Kindle Fire.

The consequence, says Glazman, is that:

technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying.

The further consequence, and this is Glazman’s strongest point, is that other browsers will have to pretend to be WebKit and support its extensions in order to give users a good experience – even if they have their own vendor-specific extensions that support the same features:

All browser vendors let us officially know it WILL happen, and rather sooner than later because they have, I quote, "no other option".

Glazman says “all browser vendors” which suggests that even Microsoft will do this, though that would be a surprising development.

This would mean that the -webkit- vendor-specific extensions were no longer vendor-specific. It would also meant that WebKit is in effect able to create web standards without the bother of going through the W3C:

It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That’s not a question of if, that’s a question of when.

says Glazman, suggesting that there is a risk of a return to the bad days when the dominance Microsoft’s IE6 prevented standards from evolving.

The parallel with IE6 is weak. IE6 was not an open source project, and the damage it did was in part because Microsoft deliberately chose not to invest in advancing HTML, preferring to drive users towards rich internet-connected Windows applications. It is difficult to see how that can happen to WebKit.

Nevertheless, the situation with WebKit is making it difficult for other mobile browsers to compete and does undermine the standards process. This is not really the fault of the WebKit team, though the W3C would like to see support for obsolete vendor-specific extensions dropped more quickly to discourage their use. Rather, it is a consequence of web authors seeing little value in adding support for other browsers that have little actual use on the mobile web.

It is worth observing that Glazman is a Mozilla guy, and his company Disruptive Innovations makes Mozilla extensions.

How can this be resolved? Glazman and others are right to raise awareness of the issue, but I doubt that many outside the standards community or browser vendors themselves will see this as a major problem.

The best fix would be for non-WebKit browsers to become more popular on the mobile web. Growing use of Windows Phone, for example, would give web authors more incentive to fix their markup. Another route to improving standards is via tools which do the right thing. Adobe’s strong support for CSS in Dreamweaver, for example, gave a significant boost to its use and helped to rescue us from font tags and the like.

Finally, it seems to me that the distinction between the “mobile” web and the “full” web is blurring, and rightly so. Users on mobile devices often tap the “full site” link where available since they have big enough screens to benefit. WebKit does not yet dominate the desktop Web. 

Why Microsoft is scrapping the MIX conference

Microsoft is scrapping its MIX conference, according to General Manager Tim O’Brien:

we have decided to merge MIX, our spring web conference for developers and designers, into our next major developer conference, which we will host sometime in the coming year. I know a number of folks were wondering about MIX, given the time of year, so we wanted to make sure there’s no ambiguity, and be very clear… there will be no MIX 2012.

O’Brien says that MIX started in the aftermath of the 2005 PDC because:

there was a lot of discussion around our engagement with the web community, and how we needed a more focused effort around our upcoming plans for Internet Explorer, the roadmap for our web platform, the work we were starting on web standards (we were shipping IE6 at the time), and so on.

That is not quite how I recall it. PDC 2005 was the pre-Vista PDC, no, not the “three pillars of Longhorn” in PDC 2003, but the diluted version of Longhorn that was actually delivered as Windows Vista. One thing Microsoft really did get around this time was that design mattered. Apple had cool design, Adobe had cool design (and a strong grip on the designer community), but Microsoft did not.

Windows Presentation Foundation (WPF) was intended to win designers to the Windows platform, with its graphically-rich and multimedia-friendly API. In order to do this, the company needed to win designers over to the idea of using Expression Blend rather than Adobe Flash and Photoshop.

This was doubly true when Microsoft decided to bring WPF to the browser in the form of Silverlight, a decision that was announced at PDC 2005 and expanded on at the first MIX in 2006.

One of the things I recall at the first and second MIX events were groups of bemused Flash designers who had been bussed in by Microsoft to enjoy the lights of Vegas and learn about Blend.

General web authoring was a factor as well, as Microsoft sought to bring Internet Explorer back on track and to persuade web designers of the virtues of Microsoft’s web platform.

I enjoyed the MIX events. They were small enough that you could easily get to speak both to attendees and to the Microsoft folk there, and once you allow for the fact that Vegas is Vegas, the atmosphere was good.

As an attempt to appeal to designers though, MIX was a failure. It was all too forced; many of the people attending were developers anyway; and Microsoft itself included more and more developer content in ensuing MIX events.

The 2010 MIX was hijacked by Windows Phone 7, an interesting topic but drifting far from the original intentions.

It comes as no surprise to hear than MIX is no more. It is associated with WPF and Silverlight, neither of which are now strategic for Microsoft in these days of Windows 8 and the Windows Runtime (WinRT).

That said, Microsoft still has difficulty appealing to designers.

What next then? O’Brien says:

we look ahead to 2012 and beyond, the goal is to ensure that global Microsoft developer events are of the caliber that many of you experienced at BUILD last September, in addition to the thousands of online and local developer events we host around the world to support communities and connect directly with developers. We will share more details of our next developer event later this year.

image

The mystery of unexpected expiring sessions in ASP.NET

This is one of those posts that will not interest you unless you have a similar problem. That said, it does illustrate one general truth, that in software problems are often not what they first appear to be, and solving them can be like one of those adventure games where you think your quest is for the magic gem, but when you find the magic gem you discover that you also need the enchanted ring, and so on.

Recently I have been troubleshooting a session problem on an ASP.NET application running on a shared host (IIS 7.0).

This particular application has a form with some lengthy text fields. Users complete the form and then hit save. The problem: sometimes they would take too long thinking, and when they hit save they would lose their work and be redirected to a login page. It is the kind of thing most of us have experienced once in a while on a discussion forum.

The solution seems easy though. Just increase the session timeout.  However, this had already been done, but the sessions still seemed to time out too early. Failure one.

My next thought was to introduce a workaround, especially as this is a shared host where we cannot control exactly how the server is configured. I set up a simple AJAX script that ran in the background and called a page in the application from time to time, just to keep the session alive. I also had it write a log for each ping, in order to track the behaviour.

By the way, if you do this, make sure that you disable caching on the page you are pinging. Just pop this at the top of the .aspx page:

<%@ OutputCache Duration="1" Location="None" VaryByParam="None"%>

It turned out though that the session still died. One moment it was alive, next moment gone. Failure two.

This pretty much proved that session timeout as such was not the issue. I suspected that the application pool was being recycled – and after checking with the ISP, who checked the event log, this turned out to be the case. Check this post for why this might happen, as well as the discussion here. If the application pool is recycled, then your application restarts, wiping any session values. On a shared host, it might be some else’s badly-behaved application that triggers this.

The solution then is to change the way the application stores session variables. ASP.NET has three session modes. The default is InProc, which is fast but not resilient, and for obvious reasons not suitable for apps which run on multiple servers. If you change this to StateServer, then session values are stored by the ASP.NET State Service instead. Note that this service is not running by default, but you can easily enable it, and our helpful ISP arranged this. The third option is to use SQLServer, which is suitable for web farms. Storing session state outside the application process means that it survives pool recycling.

Note the small print though. Once you move away from InProc, session variables are serialized, not just held in memory. This means that classes must have the System.Serializable attribute. Note also that objects might emerge from serialization and deserialization a little different from how they went in, if they hold state that is more complex than simple properties. The constructor is not called, for example. Further, some properties cannot sensibly be serialized. See this article for more information, and why you might need to do custom serialization for some classes.

After tweaking the application to work with the State Service though, the outcome was depressing. The session still died. Failure three.

Why might a session die when the pool recycles, even if you are not using InProc mode? The answer seems to be that the new pool generates a new machine key by default. The machine key is used to encrypt and decrypt the session values, so if the key changes, your existing session values are invalid.

The solution was to specify the machine key in web.config. See here for how to configure the machine key.

Everything worked. Success at last.

Adobe discontinues Flash Catalyst, clarifies Flex and Flash Builder futures

Adobe has told a group of Flex developers, invited to San Francisco for a special reconciliatory summit following the sudden announcement that Flex is moving to the Apache Foundation, that Flash Catalyst will be discontinued. Developer Fabien Nicollet was there and posts:

CS5.5 version of Catalyst is the latest version of Flash Catalyst. It is compatible with Flex 4.5, but compatibility will not be ensured for future versions.

Flash Builder will also have features removed in future versions. Adobe’s slide talks of:

Removing unpopular and expensive to maintain features: Design View, Data Centric Development (DCD) and Flash Catalyst workflows.

The Monocle profiler, shown at the MAX conference as a sneak peek, “continues as a priority”.

The FalconJS project, to compile Flex to HTML5, will be discontinued, though possibly donated to Apache at a date to be determined.

AIR on Linux will not be given to Apache because it would mean sharing the proprietary Flash Player code. This is bad news in the Apache context.

Nicollet concludes:

Flex still has a bright future for companies who want to build fast and robust applications . Not to mention the people who will have a hard time building complex applications on HTML5, for whom Flex will always be a viable and mature alternative.

That is the optimistic view. What is clear from the summit is that Adobe is greatly reducing its investment. I guess we knew this already; but hearing about how Flash Builder will be cut-down, Catalyst discontinued, and so on, will not improve developer confidence.

A lot depends on the progress of the Apache project. My concern here is that since the Flash player, which is the Flex runtime, remains proprietary, this will dampen enthusiasm in the open source community and limit its ability to innovate around Flex.

Sencha’s Michael Mullany talks about Flash developers “flailing around for an alternative” and the Big App Rewrite

I spoke to Michael Mullany, CEO of Sencha, a company which creates HTML5 frameworks and tools for desktop and mobile browsers. Ext JS is aimed at desktop browser applications, while Sencha Touch is for mobile devices, currently Apple iOS, Google Android and Blackberry 6+. Sencha’s tools include Ext Designer, a visual application builder for Ext JS, and Sencha Animator, a designer for CSS 3 animations. Sencha Touch apps can also be packaged as native apps for iOS or Android.

At its developer conference in Austin USA earlier this month, attended by around 600, the company announced Sencha.io, a cloud service for mobile web apps, as well as presenting Sencha Touch 2.0, a major update.

image

Mullany talks on his blog about “The Big App Rewrite”:

It’s a world where HTML5 powers the client apps, and they’re enriched with local APIs that execute on everything from traditional desktops to Smart TV’s. And cloud services provide the fabric that enables continuous, shared experiences across the diversity of end-devices. We think this is the platform for the web.

Sencha is perfectly in tune with the trends towards cloud, HTML5 and mobile, which is why I was keen to speak to Mullany. I asked him to contrast Ext JS and Sencha Touch with JQuery and JQuery Mobile.

JQuery is a pretty tiny library that helps with Dom abstraction and animations but that’s it. JQuery UI gives you some visual components as well but Ext-JS is the full enchilada. It’s supposed to be the web equivalent of Cocoa or the Microsoft Windows presentation foundation. It’s got an event system, a theming system, a very rich set of user interface controls, its object oriented, and it’s got a complex layout system so you can build nested layouts that have very complex event handling among different parts of the user interface. We’ve seen user interfaces that have several thousand data elements on a page.

It also has a model-view-controller architecture library on the client side so you can structure your code properly for large applications, it’s got a theming system so you can variable-ise your colours, shapes and look and feel very easily. It also has a full data package so you can do very rich data manipulation on the client, bind data in various complex ways across variables, it’s very different than J query.

And just like you’d probably never use Ext-JS on a public web page, you’d never use JQuery to build something like Marketo or Salesforce VisualForce or a Documentum content management system, all of which use Ext-JS. Ext-JS is one of the most popular behind the firewall development libraries for desktop development.

Now on the mobile side the difference is slightly less. JQuery mobile does give you a set of user interface widgets, but the difference is also similar to the desktop … Sencha Touch is designed to let you do anything you could do with Cocoa Touch or an Android SDK or a Windows Mobile SDK. Its intent is to equip you to develop native quality experiences with native style interaction, things like fixed user interface chrome, multiple independent scrollable areas, nested layouts, those kinds of capabilities.

Our performance tends to be better cross-platform, we’ve done more performance work, we have our theming system, we have an MVC library, we have a templating system. With JQuery mobile you tend to want to add multiple things together and you can certainly assemble a collection of things that will look like Sencha Touch, but Sencha Touch is designed to be integrated, everything is designed to work the same, and the general feedback is that even though Sencha Touch is a much richer system that takes some insight to learn, you get better applications out of it.

I also asked about the new cloud service, Sencha.io. A notable feature is that according to Mullany developers do not have to touch the code that runs on the cloud, they just call its API from the client:

We call it the first client-centric HTML5 cloud, which is a set of authentication, data, data synchronisation, and geo-location services that help people build mobile applications without needing to write server side code. So you literally write your client side application in HTML 5 using Sencha SDKs and then you store your user’s data and you store your user’s authentication credentials in our cloud. You don’t have to worry about mucking around with anything from Ruby on Rails to PHP to Java, it’s all abstracted behind these very clean APIs. We think that’s the future of mobile development, that you’ll have these very thin abstracted server-side services, and and these very rich mobile clients that have off-line state and local data storage powered by HTML5. We think that model is the future of mobile web development and we obviously hope that Sencha.io will be the most popular back-end.

Sencha’s frameworks are open source and dual-licenced. You can use both Touch and Ext JS freely under the terms of the GPL v3. There is also free commercial licencing for Sencha Touch, while commercial licences for Ext JS are paid for. Sencha also has commercial tools, and I asked Mullany to describe the tool products:

We really see the three legs of the business being cloud, tools, and SDKs. We just did a preview of the Sencha Designer 2.0 release at our conference. That has support for Sencha Touch in it so you can drag and drop Sencha touch applications together and then actually package them from within the tool. The intent is also to allow you to hook up to cloud APIs from within the tool as well so it is an integrated, easy-to-use visual application builder for both desktop and touch. So that’s targeted at developers.

Sencha Animator is a little bit different. There’s no JavaScript in it really at all. It is a pure CSS 3 animation tool, and it is a traditional visual timeline with keyframe manipulation, and a style visual editor for creating rich animations.

The market we’re targeting for that is people doing interactive brand advertising on mobile. That’s where you have ubiquitous support for CSS 3 animations that are hardware accelerated so they tend to be the best performance. It’s also very web content friendly so you don’t have to write your application in Sencha Touch just to use Animator, it’s pure CSS output that you drop into whatever piece of content that you want to build.

The reason we built it is because we saw people flailing around for an alternative to doing Flash ads on mobile. Because Flash was banned from iOS, it meant that a whole segment of rich advertising that was based on Flash for the desktop had nowhere to go. They weren’t going to build native iOS applications, it had to be web. So the question then was what do you build it in, do you use JavaScript animation, do you use SVG, do you use Canvas, do you use some of the other graphic technologies such as Web GL? The answer is that CSS 3 is really the highest performance and cognitively pretty easy to wrap your head around.

People “flailing around for an alternative to doing Flash ads?” Mullany has his own agenda, but his comments do highlight the problems caused for Adobe by the success of Flash-free iPhone and iPad. I cannot help thinking that Sencha would be an attractive acquisition for Adobe or certain other companies, but I am sure smarter people than myself have thought of that.

Post sponsored by Monster for the best in IT jobs.