Tag Archives: Windows 8

How Many Monitors?

I’ve been upgrading some PCs at home recently, and one of the topics we’ve been discussing around the family is what kind of monitor(s) would suit everyone’s needs.  It was logic to extend that study to what kind monitor / display arrangement suits developers.

I’ve come across this kind of discussion in various blogs, and one thing that has struck me is that there is little distinction between home and office requirements.  This is probably down to both the prevalence of contract workers, as well as a shift toward some portion of time working from home.  Indeed, with the availability of some interesting hardware devices, even travelling developers, i.e. laptop users, also have many options available to them (i.e. when not actually travelling).

So, the main choices facing developers are … how many screens do I need, and how big should they be?  It ends up being quite personal, though I’ll try to discuss some influencing factors.  It’s a good idea to have a “home” screen, i.e. where you want to be continually updated with emails or some web content.  You would typically arrange a few application windows to fit the screen.  Hopefully these windows’ co-ordinates can be saved by these applications.  Essentially this is the concept behind Windows 8 live tiles.

For actual development I’d suggest 2 screens, one for source code editing and the other for testing / troubleshooting.  You might justify extra screens if you need two different source code editors (e.g. for polyglot development), or if the deployment environment is complex and possibly deployed over additional servers.  Screen size could be driven by budget, aesthetics or just … how good is your eyesight!  If utilising the screens for gaming as well, then I’m told refresh rate is very important.

Assuming your set-up has one workstation controlling everything, all of your screens will be extending the desktop.  Windows 8 has useful new features to support extended desktops including extending the wallpaper and the taskbar.  At last, there is somewhere to see those well stitched panorama photos that you created when you were exploring your new camera’s features.  You can also choose completely different wallpaper on each screen.

If you are lucky enough to have a permanent workstation set up, then you have maximum hardware flexibility, and only your budget is a limiting factor.  The main advantage over laptop users is that you can make sure that all screens have the same resolution.  This is handy if you move windows around between screens as they will always maximise to the correct size.

Laptop users have to make some compromises as it’s assumed that at some time you will run some of those development applications that would normally exploit multiple screens, away from your normal environment, i.e. run them in one screen.  Sometimes you can borrow one foreign screen, but it won’t be the same as the home environment.  So here’s a tip that I’ve learnt from hard experience: always drag all windows back to the laptop screen before shutting the application down.  Disconnecting the extra screen whilst your program is still running has lead me down futile troubleshooting paths, even re-installing software, all because I though the program was broken / corrupted etc., when it was just waiting for input to a secondary window that was displaying where the second monitor used to be displaying that window.

Modernizing an Existing UNIFACE Application

It is always good if the UNIFACE lab invents beautiful widgets like the tabEx or extends the command button. But what if you have an existing application running and you don’t have the means to break it open to change it? This blog post’s focus is on changing the look and feel of an existing application without opening the sources. Further in the post, I give a sample on color inheritance which also can be used in combination with the newly introduced options for styling.

In the past the UNIFACE lab introduced new ini file settings for “window”, “defentity” and the “shell”. The idea behind these logical widgets with their properties is that an existing UNIFACE application can be styled after it is implemented without breaking open the sources. This enables a value added reseller to deliver an application in the colors of a particular customer while for another customer logos can be added to forms or application shell.

In UNIFACE 9.6 this approach of restyling the application is brought to an higher level. Added are the menu’s, Tab widget, panels and the command button. Together with color inheritance, I tell later more about this, it is a complete set. Still the lab is extending the list of widgets supporting the individual style attributes or properties as they are called.

The following picture shows the old gray and boring menu which is the standard windows menu in IDF:

Image1

By defining the menu=umenu() and some colorful property value’s things start to look completely different:

Image2

If we copy the properties from the menu to the panel we can blend the panel with the menu’s:

Image3

Many properties of the menu will be ignored by the panel, but as a lazy developer I like to copy the long property collection of the menu into the panel=upanel line. And indeed it works and looks good, if you like light yellow back ground with red letters.

Do not forget to set the panel definition in the setup to “user defined:”

Image4

With this setting the panel=upanel line is read by the UNIFACE runtime.

That same property line can be copied to the commandbutton widget. Only here you have to add the representation=UNIFACE property otherwise all color properties are ignored.  If you run on Windows eight it is good practice to set the backcolorfill property to “flat” since Windows eight has a flat interface.

TabEx Widget

The TabEx widget is a drop in replacement of the existing tab widget so you simply can change the Tab=utab into tab=utabex in the usys.ini file. If you do not specify any property nothing will happen, it looks old and gray.  The following picture is a screen shot of the IDF signature editor:

Image5

By defining some dodger blue colors the looks can change to:

Image6

And for Windows 8 we use the backcolorfill= flat:

Image7

Color inheritance

In many cases labels have a color=NO setting to blend them into the underlying form. If we change the background color of a window in the usys.ini we can also specify a fore ground color for the form or entity. You cannot see this color directly but when the label has the inheritcolors property set in the usys.ini it will show the form foreground color  as well. The checkbox, radiobutton, label and the editbox support this inheritcolors property.

This property becomes very valuable when you use a contained form which lives on different forms in a tab widget or form container. The widgets blend in the form when using the inheritcolors property in the label, checkbox and radiobutton widget. You can use this setting on an editbox however this may conflict with standard GUI look and feel. Here is a contained form with no colors at all. For all widgets the inheritcolors is switched on:

Image8

When we show this form in a container which parent has a forecolor=red and backcolor=darkseegreen1 we get the following:

Image9

What happened in this case can be seen in the next table which shows the color inheritance of the label in the contained form:

ForeColor BackColor
Form Red Darkseegreen1
Entity NO NO
Container NO NO
Form NO NO
Entity NO NO
Label Inherits Red Inherits DarkSeeGreen1

So the label searched all the way up for a color and found the foreground color in the parent form as well as the background color.

Suppose we make the entity on the contained form light yellow with blue then the color of the checkbox and radiobutton will automatically inherit this color:

Image10

The following table shows the search path again and here the color of the entity is taken:

ForeColor BackColor
Form Red Darkseegreen1
Entity NO NO
Container NO NO
Form NO NO
Entity Blue LightYellow
Label Inherits Blue Inherits Lightyellow

Removing the lightyellow only makes the label again darkseegreen1 and the fore color stays blue.

So far this small intermezzo on colors and styling. I hope this helps you in pimping an existing application without too many headaches on code changes.

Windows 8 and market momentum

I’ve been quite open about not being a fan of Windows 8.  I’ve mentioned it in previous postings.

I’m currently shopping for a new TV, and while I was in the big electronics store close to the office, I had a look at a Windows tablet running Windows 8, the first time I’d really looked at one. I have to say that when I’m using my fingers, and I’m swiping and poking (I have fat fingers!), I can see the value of the tiled interface. But as soon as it’s keyboard and mouse interaction, personally I find it annoying.

I see that  there are some whispers in the market place that Microsoft are considering significant changes with the update they are calling Windows ‘blue’ at least as an internal name. There is an overview on the BBC website which caught my eye.  I wonder if this will bring the changes which will make Windows 8 be used more in business that it seems to be. We’re not seeing much traction within the Uniface customer base and curiously not even the US, which is usually the leading market to pick up new technologies.

Should I Slide or Should I Swipe?

 

Touch interactions in the User Interface were new several years ago, with the advent of new portable devices.  But in my sphere of development technology interest, it is Windows 8 that is introducing touch interaction to a much bigger audience of developers.  Yes I know Windows 7 also had touch, but how many laptops, or 27 inch workstation monitors, were touch-enabled?  If you still get junk mail catalogues from electronics discounters, you will see the new models of Windows 8 machines that are more and more touch-enabled.  Even the touch-pad has become more powerful.

So the Operating System will confront users and teach them to accept, and even embrace, touch interactions in the UI.  It is therefore inevitable that application developers will need to accept and embrace touch interactions as well.

Before we start development, there are interesting design paradoxes to resolve.  For example, Microsoft suggests that whilst touch interactions should be adopted in new applications, keyboard and pointing devices should continue to be fully supported**.  So do you design to maximise a UI as if touch were the only interaction method, or do you compromise it to accommodate a wider choice of interaction devices (please don’t call a mouse an old or legacy device)?  Another example comes from the desire to develop a single code line for all deployment scenarios.   We can handle different OS and DBMS combinations, but in the future, target screen size and resolution may vary enormously.  Font and window sizes can be changed dynamically to compensate, and we can even alter the layout of objects, but the size of our (adult) fingerprint, and the distances between fingers etc., won’t change to suit.

Suppose that we are ready to develop, and we have all the software tools that we need.  Unfortunately we will have to learn new terms and concepts.  We will have to understand the differences between gestures, manipulations and interactions.  The MSDN reference below can be expanded to find Microsoft’s definitions as an example.  If you look at gestures, you can see that Slide and Swipe are considered different gestures.  How can that be?  One of the interactions is Zoom … sounds intuitive, but there are 3 kinds; Optical zooming, Semantic zooming and Resizing.  OK, we can learn all this, but unlike a user of gestures in modern applications, where the attraction is speed and intuitive actions, programming for it can be the opposite, at first.

I am confident that we will be developing interesting applications in the future that will include touch interactions.  This will be matched by various challenges along the way (functional testing sounds challenging).  BTW, a Swipe is a short distance version of a Slide – so I’d still be a bit careful about allowing both of those gestures in the same business function.

**    http://msdn.microsoft.com/en-us/library/windows/apps/hh700412.aspx

 

Banking on Apps

Guest contributor, Paul Herzlich, Principal Analyst, Creative Intellect Consulting

Creepy crawlies on the desktop

A friend of mine says she’s completely distracted by the tiles on her Windows 8 desktop. “It’s like a picture gallery on the staircase at Hogwart’s. Things that shouldn’t move are always squirming.” I have sympathy. I also find it distracting. But what astonishes me even more is that we’ve been here before. Doesn’t anyone remember ‘Active Desktop’? Remember how we were all going to watch live feeds of weather, news, pictures and share prices through OCX controls embedded in our Windows 98 desktops? That idea crashed along with the shares. You don’t remember that? There’s my answer. Neither did anyone in Redmond on the Windows 8 team. Why would they? That was almost 15 years ago!

The short memory of people in this industry is a constant worry to me. Youth drives innovation but must we constantly revisit the failed experiments of the past? I know the answer is, yes, because conditions change, but if we are going to try again, we need to be clear about what has changed to give something a chance to work a second time.

It is in this frame of mind that I’ve been musing – for a couple of years now – on the state of software applications. And here’s the confusion: should I now really say, on the state of Apps? While the world marvels at the remarkable democratization of software creation and consumption, I find that I am constantly faced with what I consider to be a mess of software that creates quite a few obstacles to getting things done. Since I am talking about ‘getting something done’, we can exclude everything to do with entertainment, although I suspect some of what bothers me is equally an obstacle to ‘having some fun’. Anyway, if it stands in my humble way, I’m sure that it is also costing organizations dearly.

Looking at how first the Internet and now mobile (and soon wearable) technology have/are churning up the whole of application delivery – from the process to the product – I find myself wondering, are we actually making any progress? Just what is the right architecture for applications? Do our current technologies support it? How did we get here? Have we been here before?

Programs and data

Part of my disquiet is over something I thought was a fundamental principle of application design: separation of programs and data. However, we’ve never been 100% sure that separation was needed, and when they were separated, we’ve had different ideas about which one is more important.

Let’s take a stroll through application history. In the beginning the line separating programs and data was blurry. There was some external storage (think paper tapes, cards) but a lot of data was stored in program memory too. Pretty quickly more external storage options were added. Computing became ‘data processing’. You had your data; you had your programs to process it. By the 1980’s this dichotomy was entrenched in the mainframe world. You designed your data and then you designed your programs to process it. Designers and programmers had data models. But in operation, the program was king. Operators ran programs.

Come along microcomputers (pre-PC) and we’re again using devices and languages that don’t easily process external data. You have computers with no external storage, and Get and Print are the only instructions for retrieving unformatted data. In architectural terms, the distinction between data and program is blurred. The program is once again king of computing on micros and then PCs.

This centrality of programs in the PC world continued but another idea took hold in the world of the Macs. Mac users got used to opening documents that brought up the programs that created them. Allegedly users weren’t concerned about word processors, but their reports. The idea transferred over to PCs in the 1990’s. We started to be aware of associating the file extension to a program to allow us to open a document directly. This was followed by a move to create ‘composite’ documents (think Excel spreadsheets embedded in Word documents) and the wars between rival standards (OpenDocument and Open XML).

What did users really do? In fact, they largely continued to open programs and create simple, not composite, documents.