WPF etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
WPF etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

Perşembe, Haziran 04, 2015

Is WPF dead: the present and future of WPF


As a WPF developer for years I was recently concerned by the new direction chosen by Microsoft on its client platforms with the rise of the brand new WinRT framework.
I was concerned for good reasons: I’ve suffered from the collateral damages of theSilverlight failure, and as the proverb says “once bitten, twice shy”.
Since 2009 I have put a huge personal and professional investment in WPF, using it to develop LOB applications in the financial industry, and now I’m even providing training on this topic.
So as a professional developer and trainer the future of WPF is critical for me so I’ve studied this issue more thoroughly.

In this article I’ll share my findings with you, in a completely objective and transparent manner, and I hope you’ll provide your own facts, so that the community can have a better vision of the future of WPF.
In the last part of this article I provide some strategies for businesses and individual developers.

Some reasons to worry

First I’ll start by presenting the signs that are worrying me, and should worry you too if you are a WPF stakeholder.

WPF team’s blog is idle

As every Microsoft technical team the WPF development team owns a blog where the team’s members share their expertise on WPF with the community.
The last article of this blog is dated from may 2011 so more than 3 years ago, precisely when WinRT was starting to emerge as the next big thing.
An idle blog could mean a lot of things but IMHO nothing good: probably the team was reduced to the bare minimum and animating this blog is not a priority, maybe the best members of the team have been moved to other projects like WinRT, and maybe this is intentional to send a signal to the community…
In terms of public relations an active blog is essential because it shows the technology is evolving and is developed by enthusiast developers proud of their work and willing to share it with the community.
Note that often the MSDN blogs are not very active, the Entity Framework team’s blog being one of the exceptions, thanks to Rowan Miller who regularly publishes new posts, and this is one of the main reason I like this technology: it is being developed by brilliant and committed people.

The official WPF toolkit is idle

The WPF Toolkit is a free and open source project developped by the Microsoft team and designed as the anteroom of the official WPF releases.
As an example the DataGrid was not present in the initial release (WPF 3.0 and 3.5) but was available in the toolkit, and was finally added to WPF 4.0.
The official toolkit played this role till 2010, but since then the project is idle, so seems like there is no more stuff in stock for a next release.
Sign of this inactivity: for the “WPF Toolkit” search Google ranks the official WPF toolkit second after a non official one (more on this one in the second part).

No more certification

The official WPF certification (70-511) will not be continued and it will expire at summer 2015.
This is a strong explicit sign given to developers that they should not invest more time in this technology and instead devote their time to WinRT which benefits from new dedicated certification paths.
Maybe Microsoft will step back and postpone this removal like it did with other certifications after the developers community complained, but that won’t change the fact WPF is no more the priority.
Personally I’m still hesitating to pass it because I have no guarantee the time and money (yes as an entrepreneur I pay my certifications myself) are worth it.
Instead I prefer to prepare for the WinRT certifications which should be there for some years.

No Windows 8+ integration

If you remember the release of WPF 4, a large part of the enhancements were dedicated to Windows 7 integration like taskbar items customization (jump-lists, progress, overlay…).
There is no such things in WPF 4.5 to allow full integration to Windows 8+ features like the charm bar and the numerous application contracts though there is some interop capabilities.
So if Microsoft has not invested in this integration it clearly demonstrates that WPF is no more a first-class citizen in Windows and it prefers to dedicate all its workforce to WinRT, and I think this is a reasonable decision.

No support for Windows RT

Microsoft, historically a softwares vendor, is diversifying its business by becoming anhardware vendor, mimicking its competitors Apple and Samsung.
To this end Microsoft has acquired Nokia to benefit from its long time presence in themobile phone market.
On the tablets and laptops side, to compete with iPad tablets and MacBook Proslaptops, Microsoft has launched the Surface series.
There were 2 versions of the Surface 1 and 2 depending on the hardware architecture:x86 and ARM, the later benefiting from a dedicated version of Windows: Windows RT(not to be confused with WinRT which is a software layer).
But Windows RT does not support (at least officially) the older APIs like the good oldWin32, hence does not support all the “wrappers” like WinForms and … WPF, so you can’t run your WPF applications on all the Surface versions.
And if Microsoft did not invest in this it’s simply because it tries to get rid of Win32 to replace it with WinRT which is specially tailored for the new IT trends.

The new Microsoft’s strategy

In february 2014 Microsoft named a new CEOSatya Nadella, who comes from the cloud division of Microsoft.
He is replacing Steve Ballmer, who did not understood the new mobile market (firstiPhone and Android) and is probably one of the reasons Microsoft completely missed the boat and is now fighting hard to get a place taking market shares to competitors (Apple, Samsung) percent after percent.
Contrary to his predecessor Satya Nadella’s global strategy for Microsoft is “cloud first and mobile first“, so exit the traditional desktop model, and again this is a very sane strategy.
But precisely WPF was designed for the “old” model: fat desktop applications, whereas WinRT uses a totally different model, taking into account the new mobile needs.
Of course the desktop and PC market is not dead, far from it, but it is not the predominant model anymore.
And Microsoft has taken this into account when building WinRT because you can now use the whole HTML/CSS/JS stack, including frameworks like Angular and Knockout, to develop desktop applications; a strong sign confirming that web technologies are really becoming ubiquitous (after Node on the server).

The Windows Store

In order to capture a part of the applications vendors revenues most of the platforms’ owners like Apple and Microsoft have created “stores” you must use to publish and buy applications.
And unfortunately AFAIK the Windows Store applications must be based on WinRT, so your WPF applications can’t be deployed through the store.
Note that this is not an issue for businesses that deploy their applications internally and don’t need a store, nor for big applications vendors like ERP who use their own commercial channels to sell their applications, but this is an issue if you are a small vendor who need the visibility of the store, before a competitor eats your market shares.
More and more people are using the stores instinctively to search for new applications so there is almost no way around them.
So if you intend to develop your brand new application in WPF you will have a hard time distributing it and even harder if you intend to sell it, so you should instead use WinRT.


You probably consume a big part of your daily content through your mobile phone using web or native applications so you understand how important it is nowadays to be present on this market: you must provide a mobile version of your applications.
WPF has never been a platform for mobile development and is not a player in this market, and for years the answer was Silverlight for Windows Phone and it was the reference toolkit up to Windows Phone 7.
But using one toolkit per platform was not ideal, even though you could share most of the procedural and markup code.
WinRT is an answer to this issue because it is a common toolkit designed to ease development on all the Windows platforms which are more and more unified at the OS level with Windows 8+.

Note that for a really cross-platform development that also targets Android et iOSMicrosoft does not provide any tool, so you have to turn to Xamarin which is a really promising project.

Costs of maintenance

If you’ve worked with Microsoft technologies for years you know that Microsoft spends its money sparingly, and for good reasons: first, as a company, it must make money to survive and nowadays shareholders ask more, so a penny is a penny, second implementing even a small feature is costly because there is a lot of steps involved; Eric Lippert gives an overview in this blog post: How many Microsoft employees does it take to change a lightbulb?.
So when the community asks for a bug fix or a new feature, it is implemented only if it’s really a big one:
– either critical like security breaches, so even a few numbers of impacted users will trigger the implementation
– or minor but annoying a lot of people
Developing both WPF and WinRT would imply answering to both toolkits’ feature requests and fixing both toolkits’ bugs, this is clearly not an option, especially as Microsoft is currently reducing its workforce.


What could have “saved” WPF would be some niches, e.g. as a portable technology to develop client applications, but unfortunately this is not the case.
There is a portable version of .Net (to be pedantic, of the CLI): Mono, which runs onWindows of course but also on LinuxUnix and Mac.
And Mono is not a toy technology, it really works, with it I’ve myself already built aJenkins integration server on Ubuntu Server.
Mono supports most of the .Net framework stack but one of the few missing parts is WPF; if I remember well there was a project named “Olive” to implement it but it was never really started due to the huge work it represents, especially at the low level rendering layers.
The only UI technology Mono has implemented is WinForms, so ironically WinForms could survive WPF thanks to its portability.

The Silverlight syndrome

I once was a Silverlight developer and I’ve discovered that technologies can vanish quicker than I once expected.
Back in 2008/2009: RIA is a buzz word, Microsoft is branding its own framework, Silverlight, in businesses managers see it in Microsoft events and want it in their IT ecosystem.
So in 2010 and first quarter of 2011 we started developing Silverlight applications.
But somewhere in 2011 at one of the technical events, concerning the web, Microsoft stopped putting Silverlight in the spotlight, and instead started promoting the HTML5 ecosystem (with CSS and JS).
Officially the story had not changed for Silverlight, but I was quite suspicious, reported it, and our team decided to stop Silverlight developments, which by the way had not delivered the expected benefits (e.g. Silverlight was not plug-and-play because you needed to be administrator to install the Silverlight player :/), to instead concentrate on “traditional” WPF.
Hopefully most (maybe 85%) of the XAML and C# code was shared with WPF, so not too much was really lost, and we stopped while we were not too much committed.
And this was the right choice because in 2013 the death of Silverlight was officially announced, and more than one IT stakeholder were surprised because they had not seen the forewarning signs.
I don’t think things will be that violent for WPF, but when you’ve lived such a disappointment you stop being naive and tend to become distrustful, which in my opinion is a quality in the current IT context.

Some reasons not to panic

After reading the first part you may be starting to freak out but as often things are not completely black, they are gray, a more or less dark gray.
This second part will help you mix the white with the black, so keep reading…

Still an active team

According to Greg Levenhagen (Is WPF Dead? – NO!) there is still an active development team dedicated to WPF.
Greg does not provide any hard numbers so it’s hard to measure the development effort.
While it’s obvious Microsoft wouldn’t abandon a technology used by millions of people, having dedicated developers, not merged in other teams, is a good thing.
And still according to Greg this team is not only dedicated to maintenance of existing versions but is also preparing at least a next release (WPF 5?).
Without having the change-log of this version it’s hard to be too optimistic: probably this will be only a bug-fixes and performance enhancement version without any major features.

Still a development effort [Update 2014-11]

In november 2014 the WPF team published an article, The Roadmap for WPF, showing that WPF was still actively developed.
The team is mainly working on important issues like performances, which have been continuously enhanced since the inception of WPF, and tooling fully integrated into Visual Studio.
Maybe the more important enhancement is the full support of touch and high-density display.
Why is it so significant ? Because these are features of devices like tablets and phones, and WPF was dropped in favor of WinRT precisely because the later has been specifically designed for such devices.
This may not be a complete u-turn from Microsoft in favor of WPF but it shows that Microsoft has heard and taken into account the claims of the community.
For more information check this nice video with two of the WPF developers: The Future of WPF on Channel 9.

New tools versions

I’ve noticed a positive sign on the official tooling side of things: Prism, a set of tools and best practices for developing XAML applications, has been updated to version 5 and along with the WinRT version it does provide a new version for WPF.
As said in the first part, the official WPF toolkit is idle but another project picked up the torch: the Extended WPF Toolkit.
It is being developed by a well known extensions’ vendor, Xceed, so by WPF experts (and other Windows technologies by the way), and it is very rich with a bunch of additional controls, and most importantly the project is actively developed, latest version being from june 2014, so less than 3 months ago as of this writing.

Finally the two top MVVM frameworksMVVM Light Toolkit and Caliburn.Micro, are active, new versions are 3 months old.
So the WPF tools ecosystem is still living and evolving which is especially reassuring for businesses because they are not left with a bunch of unmaintained projects.

Change in management

At the end of 2012 Steven Sinofsky, at this time President of the Windows Division, left Microsoft.
Why would it be a positive sign for WPF? Because Steven Sinofsky was famed for being a .Net hater and not playing well with the other teams (maybe the primary reason of his departure).
And this would partially explain, along with some real technical reasons, why .Net was not used as the foundation block of the next Windows versions whereas it is one of the best piece of software ever made by Microsoft.
From the outside it’s hard to evaluate the part of gossip and the real feelings of Steven Sinofsky and their impact on the design decisions for Windows 8+.

The OS market inertia

Another good point for WPF is the fact businesses and individuals don’t migrate immediately to each brand new OS version, and for a lot of good reasons: it costs money, it takes some time, it’s risky, and often it’s simply useless.
Migrating to a new OS is a really daunting task due to the need of ensuring compatibility of the applications: those provided by an external vendor like Microsoft with Office and those developed by the internal teams, and from my experience it’s a process that can easily take 2 years.
Currently (mid-2014) the market shares of WinRT on the PC market are quite reduced:
– Windows 8 + 8.1 : ~15%
– Windows 7 : ~55%
– Windows Vista : ~5%
– Windows XP : ~25%
So for more than 80% of PCs you can’t use WinRT and have no other choice than WPF.
And in some context this is worst for Windows 8+: in the companies I know in the financial sector in France this is simply 0%, the migration to Windows 7 is not even completed everywhere, and I know some still running with Windows XP because setup of applications is not trivial.
Considering the renewal cycle is about 5 years WPF should be the unique choice for a lot of businesses till the end of the decades.

The ALM inertia

As you probably know retiring applications is costly: first you have preliminary studies with a bunch of meetings to assess the impact it will have on the business, and you have to work hard to convince some users who will sometimes put the “operational risk” joker on the table; then you have to replace them with brand new application and you must ensure there is no regression, often running both the old and new versions side by side during a certain period of time before completely switching; moreover you may have to call up your DB teams to migrate the data, the network teams to adapt the firewall rules…
It’s why businesses migrate applications only when there is a valid business reason, and a brand new technical layer is not one, so the existing WPF applications, and there is a bunch, are here to stay, and it means WPF skills will be needed in the foreseeable future, just have a look at the number of WinForms applications still in the wild, and new ones are being developed every day, whereas WPF is available to replace it since 2006.
And from a technical point of view, while WPF and WinRT are really similar, they are not fully compatible: there are still missing features in WinRT 8.1 and some quirks: to map a namespace to XAML you use clr-namespace in WPF and using in WinRT, this is enough to break XAML compatibility and discourage any flimsy will to jump!

WPF is mature

The obvious important decrease of the development effort for WPF can be worrying but IMHO it is only following a natural path every developer has experimented: a huge effort to develop the first release, then still a sustained effort for the following release that benefits from the feedback of the community, and finally a minimal effort to maintain the application.
This is exactly the path followed by WPF with a first versions (WPF 3.0 (for me was more of a beta version) and 3.5) bringing a new way of developing Windows applications, thenWPF 4 introduced some new controls moved from the toolkit, like the DataGrid, and performance enhancements, and finally WPF 4.5 introduced the Ribbon and still some performance enhancements.
So the more mature a technology is the less development effort it needs, and after 8 years WPF is a really mature technology, so the needs for new features and bug fixes are reduced.
And probably WPF has now entered the maintenance phase of its life-cycle so don’t expect frenetic development of it.

The LOB niche

If there is a domain where WPF can survive and even continue to shine this is LOB (Line Of Business) applications.
First because most of the expertise to develop them is based on .Net which is a mature platform that a lot of companies running Windows use to develop their LOB applications and won’t throw away but instead leverage as much as they can.
And some central .Net tools are not yet available for WinRT, e.g. ORMs likeNHibernate or Entity Framework, which are necessary to most LOB applications to access their relational data.
Second for some big LOB applications like trading platforms there is no benefit to use WinRT because you don’t need and even don’t want, for security reasons, mobility.
And this kind of big applications even go against the official guidelines of Microsoft for designing WinRT applications: they should be focused with a minimal set of data on the screen.

Windows Forms integration

For more than 10 years a lot of businesses have created many WinForms applications, and new applications are still being developed with WinForms, despite WPF being there for 8 years as its replacement.
Of course businesses don’t want to throw away all these applications, components and expertise just to use new toys, they want to leverage their investment as much as possible.
And AFAIK WinRT is not yet able to integrate WinForms components, so using WinRT is not an option if you want to profit from your WinForms investment.
On the contrary WPF has been designed from the start to allow integration of WinForms: using the WindowsFormsHost you can embed WinForms components inside your WPF applications.
And better, you can even integrate WPF components inside a WinForms applicationusing the ElementHost, so that you can migrate slowly to WPF avoiding the big-bang effect.

The learning curve

If you are a seasoned WPF developer without knowing it you are probably already a WinRT developers at say 80%, and if you are a business you already have 80% of the expertise to develop WinRT applications in stock.
The reason is that most of the fundamentals tools for developing WPF applications are the same for WinRT:
– same procedural languages: C#, VB.Net…
– same markup language: XAML,
– same way to link view to data: data binding, DataTemplates…
– similar architecture of applications: global structuring, resources…
– same design patterns and implementations: MVVM, INotifyPropertyChanged, INotifyCollectionChanged, ICommand…
So most of your investment in other XAML platforms like WPF and Silverlight can be leveraged for WinRT, reducing the steepness of the learning curve (remember the one of WPF when you were a newbie? ;))

WPF is rich

WinRT is not a clone of WPF and some features are not yet implemented, so if you are only developing desktop applications from a technical capabilities point of view WPF is still better.
But I put it as the last one because IMHO it is not really significant, and as WinRT will continue its evolution the gap will become smaller and smaller, but I guess some developers with really specific needs won’t be able to develop with WinRT and will need WPF.
But again the added value of WinRT is not in its intrinsic technical richness but more in the development model it offers with access to mobile platforms and the Windows store.

Strategy for the future

Whether you are a business or an individual developer you should seriously consider slowing down your technical investment in WPF, and start to build your expertise on WinRT.


As a business you can’t stop your WPF developments as long as you have some older versions of Windows, including Windows 7.
As for your existing applications, don’t worry, you don’t need to migrate them to WinRT, unless you want to benefit from its new capabilities as deployment through the Windows store.
Indeed Microsoft should ensure support for WPF for the foreseeable future; backward compatibility is something Microsoft takes really seriously.
As an example while it may be harder to setup VB6 environments in new versions of Windows it is still possible and, hence setup, your applications should continue to work seamlessly.

Depending on your available IT workforce, you should devote time to technology intelligence and have some developers starting to think about WinRT: how you could benefit from it, typically to broaden your audience, how new applications should be developed, how the existing tools and code can be reused, what are the potential issues to anticipate…
For the applications that could benefit from WinRT for mobile and tablet you can start building some migration path, which is not that obvious because WinRT is missing many features from WPF.
Start to develop proof-of-concept applications to validate the new technology in your particular context and see for yourself if it delivers.


As developers we don’t want to have technical skills nobody needs, and instead we generally must build a large enough portfolio of skills to accommodate the more businesses and projects we can to reduce the risk of being left behind.
So if you are an experienced WPF developer and you have to choose between extending your WPF skills to become an expert or starting to gain new skills for WinRT development then IMHO you should choose the second option.
Of course you’ll probably be able to do both like me, but WinRT should be somewhere on your TODO list but not your priority either.

Or you could continue in WPF waiting for the market to lack WPF developers, like is the case for older technologies like COBOL and VB6, but I fear you’ll have to wait a decade before it happens, because, with the important development of IT in businesses, for any technology there is a lot of developers on the market, particularly for mainstream technologies like WPF, so I wouldn’t count on it.
Don’t be demoralized or upset by this nth brand new technology, this is the business model of our industry: it needs to create new things all the time (remember SOA that poured a ton of money from businesses to the pockets of IT companies, their employees, their shareholders and contractors) to sell them to customers just as Apple does with its iPhone 1, 2, 3, … and now 6 and soon 42, this is how it works and fortunately we, as developers, are on the good side of the barrier, we can make a living from this entropy, and objectively all these new technologies enhance the life of businesses and individuals.


I think that the sum of all these facts is pretty clear: WPF is past and present, in the near future it will be in direct competition with WinRT, but later if WinRT gets some traction and enough market shares then WPF may become kind of deprecated like VB6 or WinForms.
Above all don’t be in denial, and have a clear picture of what happens, do not eliminate the pessimistic facts from your mind.
Do not expect a revival of WPF, there is no such thing in IT (well OK COM is kind of back in WinRT ;)), WPF is objectively not tailored for the new trends, the brand new stuff is.

Of course the picture is not all black: WPF is not dead and obsolete nor dying and obsolescent, it has just reached its peak and might slowly fade as the businesses migrate their infrastructure to Windows 8+ allowing them to choose WinRT for their future developments.
Be pragmatic and transparent: use WPF while it brings value to your clients and warn them about these facts, and help them prepare for the future.
I’ve myself updated my training material by interleaving WinRT chunks in my WPF training, and adding a slide with a summary of these facts, highlighting them depending on their significance.

But IMHO you should not invest too much in WinRT either.
Why? Because the more I play with WinRT and think about it the more I see it less and less useful:

  • if you develop a LOB application, your only target is probably Windows PC, and you need to be compatible with pre Windows 8 systems, at least Windows 7, so WinRT is clearly not an option, and you must use WPF,
  • if you want to target tablets and phones you can’t forget about 90% of the market, iOS and Android, so WinRT is not an option, and you must use either the web stack (JavaScript/HTML/CSS) or native cross-platform frameworks like Xamarin (C#) or QT (C++).
So for most use-cases WinRT is not an option.
Moreover you should note that Microsoft is heavily investing in the later technologies.
It’s probably too early to ask yourself “Is WinRT (as a final developer platform) dead ?” but I would be quite surprised if WinRT manages to get some traction and becomes a major development platform.
IMHO WinRT is only a good platform for the Microsoft teams because it allows them to share code between the different flavors of the Windows OS, mimicking the effort of Apple; but for the final developer the use-cases for WinRT are way too limited: sharing some code between PC, tablets and phones but only for Windows devices.
Probably some businesses may need only that but I doubt there is many because nowadays applications are often accessed from personal employees’ devices (BYOD) which can be anything and probably some iOS or Android.

Perşembe, Kasım 11, 2010

WindowsFormsHost: Host ActiveX and windows form controls in WPF

If you ever need to host ActiveX control in your wpf application then you can do it by using WindowsFormsHost control. Also sometimes you may need to add windows form control in WPF. you may have developed some controls in windows form technology and you don't want to rewrite this for WPF. WindowsFormsHost control can save you for this time. The following steps describes what to do to add ActiveX or windows form control in wpf application:

1. Add reference to WindowsFromsIntegration assembly which is WindowsFormsIntegration.dll. This is the assembly where WindowsFormsHost control is defined. So if you add WIndowsFormsHost control before adding the assembly reference you''ll find that the WindowsFormsHost control is not recognized in XAML (if you just drag and drop the control form toolbox).

2. Add reference to windows forms assembly which is system.windows.forms.dll. You also need to add the namespace in XAML file as shown below:


3. Add reference to the activex control. When you add reference from VS automatically generate an AxHost wrapper for the activex control. Then add the assembly reference in XAML file as shown below:


FYI, if you try to add the activex dll reference without adding the other two reference you may not get the namespace in the XAML. WindowsFormsHost control can also be used to host any control designed for windows form.

Now you can add your ActiveX control in one of two ways:

1. Add Control directly in XAML as shown below:

<WindowsFormsHost Name="wfHostControl">
      <ax:MyControl x:Name="axMyCtrl"/>

2. Add the control from code by instantiating and placing in the child property of the WindowsFormsHost control.

MyControl ctrl=new MyControl();

wfHostControl.Child = ctrl;

If you need to do something on form load its better to work on WindowsFormsHost control's load event instead of wpf application's load event.

Pazartesi, Temmuz 12, 2010

WPF - Multiline Textbox

WPF ile uygulama geliştirirken Windows Formdan alışık olduğumuz textbox ‘ların MultiLine özelliği ilk etapta göze çarpmaya bilir. Bunu kullanmak için textbox markup koduna aşağıdaki iki özelliği de eklememiz gerekmektedir.


<TextBox name=”TxtHede” text=”MultiLine” TextWrapping=”Wrap” AcceptReturn=”True” />


Herkese Kolay gelsin…

Pazartesi, Haziran 28, 2010

WPF - Dinamik olarak UserControl çağırmak

Windows form uygulamalarını geliştirirken sıklıkla UserControl kullanır ve hazırlamış olduğumuz bu kontrolleri dinamik olarak formların üzerinde gösteririz. Bu işlem için ise this.ParentForm() 'kod parçasını kullanmak yeterlidir. Bu işlem WPF ‘te biraz farklıdır. WPF uygulamalarında birden fazla form ve ekran tipi olduğu için hangi base den alacağını da belirtmeniz gerekmektir. Kullanım şekli aşağıdaki gibidir.



Pazartesi, Mayıs 10, 2010

Son Kullanıcı Deneyimi için Tasarım Süreçleri - UX Design Process

Proje geliştirme süreçleri ile bu projeleri kullanacak olan son kullanıcıları göz önüne aldığımızda projelerden beklentiler gittikçe artmaktadır. Gerek işlevsellik gerekse fonksiyonellikte artış aranırken bir yanda da yeni çıkan teknolojiler ile birlikte artık oluşturulan projelerde tasarıma da oldukça fazla öncelik tanınmaya başlamıştır. Son 2-3 yıla kadar son kullanıcı deneyimini uzan süreç geliştirme ve entegrasyon süreçlerinden ötürü geri planda bırakırken artık tasarımsal öğelerin uygulamalara uyarlanabilmesi kolaylığı sayesinde istekler içerisine girmiştir. Çok basit bir örnek vermek gerekirse, boş bir windows form oluşturup içerisine standart bir button eklendiğimizde Windows Vista öncesi işletim sistemlerinde çok basit bir görünüm ile karşımıza çıkmaktadı. Ancak bu basit görünümün sebebi windows 'un kullanmış olduğumu temadan kaynaklandığını son kullanıcılara açıklamak oldukça zor bir durumdu. Aynı uygulamayı Windows Vista ya da sonrası bir işletim sisteminde çalıştırdığımızda ise o basit, standart button 'un ne kadar görsel bir görünüme kavuştuğunu görürüz. Ya da eskiden tasarımcılar tarafından hazırlanmış olan görsel öğeleri uygulamalara entegre etmeye çalıştığımızda tasarlanan ile sunulan arasında bariz farkların oluşması proje açısısında oldukça olumsuz bir izlenim bırakıyordu.

Son kullanıcı deneyimlerini en üst seviyeye çıkartmanın yollarından biri de 3. parti yazılım firmalarının hazırlamış olduğu bileşenleri kullanarak tasarımsal zenginliğin sağlanması mümkün. Ancak bu tür yazılım firmalarının bileşenlerini kullanmanın da bariz bir sıkıntısı bulunmaktadır. PERFORMANS. Evet tasarımsal öğelere öncelik vermek istediğimizde performans konusunda bariz kayıplar yaşamamıza neden olabiliyor. Bu durumda da karşımıza seçmemiz gereken iki seçenek sunuluyor. Ya tasarımını benzersiz bir güzelleğe taşıyacağız ya da uygulamanın performanslı bir şekilde çalışmasına olanak tanıyacağız. İşte artık bizler için önemli olan bu iki seçenekten birini seçmek yerine ikisini de kullanıcılara sunabilmektir.

Kullanıcı Deneyimi için Temel Başarı Faktörü Nedir?

Biraz önce de açıkladığımız üzere daha önceden uygulamalar için cin ali gibi tasarımı ile olsun ama herşeyi yapsın yaklaşımı içinde yaklaşılırdı (Yazılımcılar bu yaklaşımı besler. Bu düşüncelerini etrafta istenene benzer örnekleri olmadığı için de son kullanıcı olan müşterilerine kabul ettirebilirlerdi.). Ancak artık müşteriler için projelerde fonksiyonellik başarı için yeterli bir etken olarak görülmemeye başladı. Artık başarılı bir projenin ön şartı her uygulamanın basit yapabildiği bir işlemi olağan üstü birşeymiş gibi gösterebilmek olarak algılanmaktadır. Eskiden bu imajı uygulamayı satan satış temsilcileri sağlar ve satış işlemi tamamlandığında bir butona basar ve o işlemi yapardınız biterdi. Ama dikkat edilmeyen bir nokta var. Müşteri için önemli olanı tekrardan anlatmak gerekirse, bir butona basıp onun bir mi yoksa iki mi saniyede mi olduğu ile ilgilenmek yerine ben bu butona bastığımda ekranda bana farklı birşey gösteriyor mu diye beklenti içerisine giriyor. İşte bu nokta da projeler üzerinde yapılacak olan makyajlar devreye giriyor. Yine butona basma örneğini ön plana alırsak veri transferi esnasında işlem yapılıyor yazmak yerine iki tane kamyon ekran üzerinde hareket ederse bu son kullanıcıyı oldukça fazla etkileyen, şaşırtan ve büyüleyen bir ekten olarak ortaya çıkması olacaktır. Başka bir basit örneği daha incelemek gerekirse, Windows 'un fare ikonlarından klasik kum saati görünümü yerine dönen bir halka ya da bayan Windows kullanıcılarının en çok hoşuna giden yürüyen bir dinozor görünümü insanların ya da son kullanıcıların beklerken sıkılmalarını önlerken hoşta bir görüntü sunuyor olacaktır. mak90_1

Kısaca özetlemek gerekirse son kullanıcıların deneyimleri için yapılacak en iyi işlem projelerin fonksiyonellik özelliklerine verilen önem kadar tasarımsal özelliklerine öncelik vermektir.

Bugüne kadar son kullanıcıların tasarımsal ihtiyaçlarını karşılamaktan bahsederken sürekli olarak bu işlemi çok basit bir şekilde Windows ortamında WPF, web ortamında ise XBAP ve Silverlight yardımı ile yapabileceğimizi açıklamaya çalıştık. Bu uygulamalarda tasarım işlemlerini bu kadar basit yapılabilmesini sağlayan faktörlere göz atıyor olalım.

Tasarımcı için Araçlar

Tasarımcılar hazırlamış oldukları grafikleri kendi kullanmış oldukları uygulamalar yardımı ile hazırlamaktadır. Ancak bu uygulamalar Visual Studio ile tam uyum içerisinde çalışmamakta ve yukarıda bahsetmiş olduğumuz sorun, eksiklik v.b. gibi durumlar ile yazılımcıları tabikii de projeyi karşı karşıya bırakmaktadır. Bu sebepte hazırlanmış olan grafiklerin Visual Studio 'da sorunsuzca kullanılması için güzel bir ürün grubu hazırlandı ve tasarımcıların kullanımına sunulmuştur. Bu ürün Expression Studio ailesidir.

Microsoft Expression Studio ürün ailesinin içerisinde yer alan araçlar yukarıdaki gibidir. Bu araçları kısaca açıklamak gerekirse,

Expression Blend: WPF ve Silverlight için grafik ve animasyon tasarımlarının Visual Studio ile uyumlu olarak tasarlanabildiği araçtır. Bu araç sayesinde tasarımcı ile geliştirici arasında köprü kurularak daha etkileşimli bir şekilde çalışmaları sağlanır.

Expression Design: Adobe ürünlerinde olduğu gibi vektorel ve Illustrator grafik tasarımlarının yapıldığı araçtır. *.psd dosyalarını düzenleme özelliği ile tasarımcıların işlerini kolaylaştırmaktadır. Ayrıca WPF ve Silverlight uygulamaların da XAML kullanıldığı için bu ürün yapılmış olan tasarımları XAML çıktı verir ve yazılımcıların işlerini kolaylaştırır.

Expression Media: Medya dosyalarını zenginleştirilmiş içerik ile desteklemek ve Silverlight için Streaming optimizasyonunu sağlar.

Expression Web: HTML, CSS, JavaScript ve Asp.Net bileşenlerini kolayca düzenleyebileceğimiz web editörüdür. Ayrıca PHP ve ASP desteği de vardır.

Expression Studio ailesi ürün gruplarının tümü ile birlikte oldukça güçlü bir paket halini almakta ve geliştirici tasarımcı arasında ki ilişkiyi geliştirmektedir. Ayrıca geliştiricilerin Visual Studio üzerinde geliştirmiş oldukları WPF ya da Silverlight projelerini tasarımcılar Expression Blend yardımı ile düzenleyebirler. Ayrıca bu düzenleme olanağının tam tersi de mümkündür.


Kısaca toparlamak gerekirse, son kullanıcıya tasarım olanaklarını kolayca sunabilmek için Expression Studio ailesine gereksinim vardır.

WPF Projesi Geliştirmenin İş Akışı

WPF projesi geliştirmek analistlerden, geliştiricilere, tasarımcılara, testçilere çok daha fazla dikkat gerektiren bir süreç sunmaktadır. İstenen son kullanıcı deneyimini çok iyi anlamak ve ihtiyaçları çok doğru olarak tespit etmiş olmak gerekmektedir. Proje geliştirme sürecini en basit ve iyi şekilde anlatan süreç aşağıdaki şemada görülebilir.

WPF projesini geliştirmek için gerekli iş süreci bu şekildedir. Şimdi adım adım neler yapmaları gerektiğine göz atalım.

1. Elicit Requirements (Gereksinim Analizi - İster Gereksinimleri)

Yazılım projelerini geliştirirken en önemli faktörlerin başında ne gibi istekler ve bu isteklere karşın ne gibi kaynakların harcanacağını tespit etmek gelir. Bu ihtiyaçları karşılayabilmek için müşteriler ile detaylı ve akıllarında yer alan bütün istekleri söyletecek kadar konuşturmak ve bilgi toplamak gerekmektedir. Bütün ihtimallerin, durumların ve senaryoların belirlenmesi ile bu süreç işini tamamlayacaktır.

2. UI Prototype (Doğrulanabilir Prototifler Oluşturmak)

Protofif oluşturmak yazılım geliştiriciler, mühendisler ve tasarımcılar arasında daha etkili fikir paylaşımını arttırması sebebiyle daha çok tercih edilmektedir. Çünkü hayallerde olan bir tasarının gerçeğe dönüşmeye başlaması ile (herhangi bir çizim bile olabilir) çok daha etkili çözümlerin ortaya çıkabileceği ve son kullanıcı deneyimi açısından çok etkili çözümler bulunabilir. Prototif hazırlamanın bir kaç yolu vardır. Şimdi bunları inceliyor olalım;

    •Yazılı Dökümanlar: Oluşturulan her projenin adımlarını ve isterlerini barından yazılı bir dökümanı olması oldukça çok önemlidir. Herhangi bir araç ve alt yapı gereksinimi bulundurmaz. Sadece bir kağıt ve kalem yardımı ile aklınıza gelenleri o an yazarak daha sonrasında detaylı bir şekilde değerlendirebilmenize olanak tanıyabilir.

    •Tasarılaştırmak: Visio, Powerpoint gibi uygulamalar ile akış ve gelişim süreçlerinin tasarlanması. Visio ile oluşabilecek kullanıcı ekranlarının tasarımlarının temel anlamda hazırlanabilmesi.

    •Expression Blend 3 - Sketch Flow: WPF ile hazırlanan uygulamaların hangi adımlarından sonra nereye gideceğini ya da ne işlemler yapabileceğine açıklamak açısından kullanılması gerekmektedir.

    •Görülebilir Prototif: Sahte veriler yardımı ile gerçek uygulama üzerinde test yapmak ve sunumlarını gerçekleştirmek olarak görebiliriz.

Prototiflerin oluşturulması test süreçlerinin daha etkili yapılması ve gelecekte oluşabilecek olan sorunların tespit edilmesi ve hazırlanan uygulamaların daha stabil kullanılabilmesi açısından oldukça önem taşımaktadır.

    •İşleyişi: Prototifin oluşturulması ve gerekli dökümanların hazırlanabilmesi için öncelikli olarak bu süreçleri takip edebilecek bir ekip oluşturulmalı ve bir kişi ekibin liderliğini üstlenmelidir. Ayrıca test yapacak olan çalışan topluluğu lider tarafından hazırlanan test dökümanlarına göre hareket etmeli ve yapılan testler sonucunda oluşan gelişimleri yine bu dökümana ekleyerek tekrardan test liderine gönderir. Bu süreç test başarılı bir şekilde tamamlanana kadar devam edecektir.

3. İş Süreçlerinin Hazırlanması ve İşin Çalışanlara Dağıtılması

4. Grafik Tasarımı

Uygulama içerisinde yoğun olarak kullanılacak olan grafiksel öğelerin hazırlanması esnasında geçen süreçtir.

5. Test Yazılımı


Hepinizin tahmin edeceği üzere bir projede çalışan çalışanların üzerine atanan roller vardır. WPF ya da Silverlight ile son kullanıcı deneyimini maksimize edecek projeler hazırlarken de proje içerisinde çalışanların rol tanımları önceden belirlenmiş ve kesinleştirilmesi gerekmetkedir. Şimdi bu rollerden ve görevlerinden kısaca bahsediyor olalım.

    •Uygulama Geliştici & Mühendisi:
Bu ünvana sahip olan çalışanlar veri modellerinin, işlevselliğin ve temel tasarım üzerinde uygulamanın yapması gereken işlevleri yapabilmesine olanak tanıyan süreci tamamlamaktadır.
    •Grafik Tasarımcı: Analistlerin son kullanıcılar ile yapmış oldukları toplantılar sonrasında tespit edilmiş isteklerini karşılayacak olan görsel öğeleri tasarlayacak olan kişidir. 3B, 2D, Animasyonlar ve diğer bütün grafiksel işlemleri uygulama da kullanılması için tasarlar.
    •Etkileşim Tasarımcısı: Grafik tasarımcısı tarafından hazırlanan tasarımları uygulama içerisinde nerelerde kullanılabileceğine karar veren ve bu kararlarını Visio v.b. uygumalar ile dökümante eder.
    Entegrasyon Uzmanı & Mühendisi: İlk olarak söylememiz gereken sektörde çok zor bulunan biz uzmanlık alanıdır. Bu ünvan ile çalışan kişiler geliştiricinin ve tasarımcının hazırlamış olduğu parçaları birleştirerek uygulamanın geliştirme sürecinin tamamlanmasını sağlamaktadır.

Son kullanıcı deneyimini arttırmak için yapılması ve dikkat edilmesi gerekenleri, çalışanların ne tür vasıflarda olması ve neler yapması gerektiğini açıklamaya çalıştık. Ayrıca tasarımcı ile geliştiricinin birlikte rahatça çalışılması için gerekli olan araçların neler olduğundan da bahsederek genel hatları ile proje geliştirme sürecini tanımlamış olduk.
Ayrıca son kullanıcı tasarım süreçlerini akış şeması üzerinde incelemek isterseniz burada yer alan PDF dosyasından yararlanabilirsiniz.

Sonuç olarak bu yazımızda en temel hatları ile WPF ya da Silverlight teknolojilerinden yararlanarak son kullanıcıların deneyimlerini arttıracak uygulamaları nasıl geliştirebileceğimizi anlatmaya çalıştık.

Umarım sizler için yararlı olabilmiştir.

Turhal Temizer