Tag Archives: Usability

New Year’s Resolution

These are the first lines I write in this new year, 2017. I want to start with wishing you all a very good and successful year. How strange is it. On New Year’s Eve we look back, while on New Year’s day we make plans and start with our New Year’s resolutions.

Some things will start, some have ended and some continue. For most of us, Uniface is one of those continuing. As I wrote before, sometimes I wonder how long it shall. But on the other hand, why care. There are thousands of software development tools. Most of them are bigger (whatever that may be) and perhaps some better than our beloved Uniface. The concept of programming is, from a certain point of view, always the same. Sure, you need to learn. You quit being a Uniface senior to become a junior in something else. You will enter a whole new world, with new and probably many young software developers. And between these hipsters you are the oldest junior they have ever seen. Wow, interesting, isn’t it? Your New Year’s resolution can be becoming a junior again!

In a previous blog I’d bet you a beer. I wrote about this company where I once worked. They tried several software development platforms. Maybe they found something else more tempting. Eventually they did choose Uniface. You did not expect that, did you! To be honest it was a close call. Right on time Uniface invited the management for a lab visit in Amsterdam. Uniface product management listened and that did some amazing magic.

But software development isn’t about magic. No fairy tale with software generating magicians. We all know that. It’s just hard work. One of the most heard complaints is the lack of standard components or add-ons in Uniface. The management of the mentioned organisation also asked this to the Uniface product management. Why do we need to build everything by our self? Why can’t we download standard solutions instead of building them?

The answer is simple: just because…

  1. Your problem is unique, no one ever had it before
  2. It’s been built, but the solution is too specific
  3. Or the solution is built in a previous Uniface version (what the f…, Uniface is upward compatible!)
  4. Or the quality is poor, there is no documentation, there is no source code available or someone wants money for it (and you believe software should be free)
  5. Someone built it before, but did not share it with you.

Is this a problem? Yes, it is. Can we fix it? Yes, we can. And I believe it’s simple. Whenever you think ‘Hey, why can’t I just find this on the web?’, do the following:

  1. Look once again, perhaps it is somewhere around
  2. Design the most generic solution
  3. Build it
  4. Test it
  5. Write some documentation
  6. And…. share it.

Maybe it’s a good New Year’s resolution. Emphasize your Uniface seniority and build to share. How? Where? Who? After reading all of the reactions on my previous posts I have a plan. I am working on it and I’ll explain it to you in the next posting.

Happy new year!!!!

The new Uniface Integrated Development Environment .. more than just a new term

Uniface 10 is all about the new environment for developing Uniface applications. To underline that, we  have given it a new name: the Uniface Integrated Development Environment, or Uniface IDE.

For thirty odd years, we have referred to our development environment as ‘the IDF’. What does the term IDF stand for? How is IDE different from IDF? Is the difference relevant at all? Here in  the Lab, we use the terms IDF and IDE to make the following distinction:

  • IDE is the development environment for Uniface 10
  • IDF is the development environment for all Uniface 9 versions.

The IDE in Uniface 10 has its own new executable, called ide.exe. You can find it in the common/bin folder.
This new IDE uses a new assignment file, named ide.asn. This file is in the uniface/adm folder.

So, some things have changed, others have not. The logical path to the database that stores the repository is still called $IDF in Uniface 10.

IDE and IDF are totally different applications with their own characteristics and a very different user interface. Added to that: the repository has been changed substantially to cater for new functionality in the IDE. So, it’s important for us to distinguish between IDE and IDF.
The Uniface 10.2 IDE is largely composed of a completely new set of editors. Editors for components, modeled entities and projects, to name a few.
And yes, the IDE still contains a subset of editors that also exist in the IDF – you will find these under ‘More Editors’ in the IDE’s top menu. Over time, the old style editors will be replaced by new style editors, i.e.  IDE style editors

Where does the term IDF come from?

Way back, in the late eighties and early nineties of the previous century, the days of Uniface versions 4 and 5, the Uniface development tool was called Information engineering & Design Facility, IDF for short. Here’s a screenshot of the IDF start screen, taken from the Uniface 5.2 manual (and notice that other terminology has changed over time!) 

Uniface 5.2 Manual
Uniface 5.2 Manual

The name idf was also used for the executable that started the development tool: idf.exe on Windows and VMS, or just idf on Unix.
To use the development tool on Unix in those days, you would typically use the environment variable $idf that was defined by the install scripts. And to keep things simple, a predefined logical database path $IDF is used by Uniface to this very day to define where the repository is stored. 

In later versions the term Information engineering & Design Facility disappeared. We introduced the term UDE, short for Uniface Development Environment. The terms UDE and Uniface Development Environment were used all over the place in the documentation,  but I don’t recall ever having seen the term UDE in the tool itself. The executable that started the UDE was still named idf.exe – we’re talking Windows only in the meantime – and the assignment file for the UDE was still named idf.asn.

Enter the $UDE function in the Uniface Proc language in Uniface 9. A function that helps the developer define custom actions on repository data, including compiling, exporting, importing, and converting. On disk, you will find a file called ude.exe. This executable is not used to start the Uniface Development environment, but is used by the $UDE function. There is no ude.asn file for the ude.exe.

And for completeness sake: for a short period in the Uniface 9 lifetime we used the term Uniface Application Platform Suite, or APSThe APS is the workbench that integrates Uniface application development with the BPM product Uniface Flow. Note that as of Uniface 9.7, Uniface Flow is no longer delivered.

Summary
Uniface IDE vs IDF
Uniface IDE vs IDF

Confused? Naah, not anymore, I hope ….

 

Uniface 10: Code containers, code inheritance and default behavior

One of the many nice, new things about the Uniface 10 Development Environment is the Code Container. Each of your development objects, like components, entities and fields, has its own container that houses all of its triggers, operations and entries, generically called modules.

Uniface 10: Code Containers
Uniface 10: Code Containers

With this new way of organizing code, Uniface 10 provides ProcScript code inheritance in a very clear consistent way; code inheritance is purely on the level of the individual module.

Simply put: a ProcScript module defined at a specific level, overrides any implementation that module might have at a more generic level. Or, from a different perspective: if you do not implement a ProcScript module at a specific level, Uniface will fall back to the implementation of that module at the nearest (inheritance-wise) more generic level.

For triggers, the most generic level is really very generic: it is the built-in default trigger behavior. For most triggers the default behavior is to do nothing, but some triggers do have real default behavior. For example, if you omit an entity’s trigger create at all levels, Uniface still adds an occurrence when the user presses ^ADD_OCC.

The code containers, and the uniform way of code inheritance that comes with them, make Uniface 10 a real pleasure to work with, especially in combination with the Compiled Modules Inspector, which you find at the right-hand side of the Component Editor’s Write Script worksheet. It shows all modules that were compiled into the component, wherever they came from. A simple double-click on any of them moves you right into the code container of the object where that code was defined.

I love it!

Uniface 10: The new procedural declaration of component variables

For Uniface 10 we are constantly reviewing and redefining old concepts, aiming for consistency and reusability while looking for new ways to improve your developing experience and enforce good development practices. This is what the new procedural declaration of component variables is all about.

If you are a developer coming from older Uniface versions you probably are familiar with the ‘Define Component Variable’ form, that allows the creation of variables with component scope and an optional display format. You certainly also know how to declare local variables using the variables block in your triggers and modules. In that case, you might have wondered while accessing the ‘Go To -> Component Variables…‘ menu, selecting the data type from a dropdown list, entering a display format and filling a couple of optional fields… Why can’t I do this from my code, like with local variables?

There are some advantages in the form approach, but the truth is that variables declaration is a fundamental part of coding, as it is the concept of variables scope. It is not only logical but even expected for new developers that variable definitions at component level have component scope. Furthermore, is it a more efficient method of defining and inspect variables. If you think that way, congratulations: You got it! If you are not convinced yet, please keep reading.

In version 10 (10.1.03 and higher) component variables are declared using the ‘variables’ block in the Declarations container of a component. You may declare as many blocks as you want, taking in account that variable redefinitions are not allowed by the compiler. The display format definition takes place -optionally- in the declaration itself, so it looks like this:


variables

DataType {DisplayFormat} VariableName {, VariableName2 ... {, VariableNameN}}

endvariables

The display format is defined using the ‘DIS(<format>)‘ syntax, as it used to be in the ‘Define Component Variable‘ form. You can find extensive documentation about display formats in the Uniface Library. As for the missing fields ‘Description‘ and ‘Comments‘… Well, nothing better than in-code comments to describe our variables.

An actual example of component variables block could be:


variables

string                         vCity, vCountry

string DIS(Mr./Ms. ??????????) vFormattedName         ;- Formatted name for official notifications

date   DIS($NLS(MEDIUM,DATE))  vStartDate, vEndDate   ;- Start/End of contract

float  DIS(9999999P99 US$)     vSalary                ;- Net salary in US dollars

endvariables

Simple, isn’t it? But here is the best part: since component variables are declared procedurally, you can use all the precompiler directives to generate, influence and include component variable declarations. Move your variables block to an include proc to make it reusable. Use the #for directive to quickly generate variables. Make use of definitions to avoid typing complex display formats and ensure consistency between components. Create a snippet library with display formats to quickly insert them into your code.


variables

;- Predefined variable declaration for error handling:

#include MYLIB::ERROR_VARS                 

#for CPTVAR in (NAME,SURNAME,CITY,COUNTRY)

string v<CPTVAR>                      ;- Generate component variables for customer data

#endfor

string <IBAN_FORMAT> vAccount           ;- Predefined printed format for IBAN code (IBAN ???? ???? ???? ???? ????)

endvariables

If you are still hesitant don´t despair: We keep working on great ideas to make code editing faster and easier, as well as providing code and compiled objects information on the editors. But more about that in another blog post…

In the meantime, leave us a comment with your thoughts about the new system! What do you like? What can be improved? How would you make the best use out of it?

Modernizing Uniface 9.7 in 10 easy steps

I have been talking about modernizing the look and feel of Uniface applications for many years. And ever since I switched from the Uniface Services department to the Uniface Lab my hands have been itching to do something with the look and feel of the Uniface Development Environment, as that is (for a large part) a Uniface application. But with Uniface 10 on the horizon there was never much room to work on the Development Environment of Uniface 9. With Uniface 9.7 we finally got the green light to do a small project to make it look more fresh against a modest budget.

Intro

We decided to follow the advice that we often give to our customers: completely redesign one important screen and just change colors, buttons etc. for all other screens.

Adrian and Mike, our product managers,  gave us the following brief:

  • New start page.
    Styling should lean towards Windows 10 Metro theme.
  • All screens should get a white background.
    Grey applications are perceived to be old, other colors tend to look less professional.
  • We should use flat buttons.
    Flat buttons are very popular now and we want to show that you can make them in Uniface 9.7.
  • It needs to look fresh and noticeably different from Uniface 9.6.
    A fresh color scheme and a new start page should take care of that.
  • Against minimal cost
    That meant that code changes in individual forms were out of the question. The testing effort alone would already be quite big.

With these not so S.M.A.R.T. requirements, Jonke and I went to work.

The new start page was fun to make. While doing it, we were a bit surprised how much functionality there is on this screen, which looks so simple at first sight. But since it is only one screen the challenge remained manageable.

Maybe there will be some more posts about the specific new GUI features that are available in Uniface 9.7.  But in this series of posts I will limit myself to the changes that we made to the start page and all Uniface forms. It may be of help to you when you want to modernize your own Uniface application.

In 10 steps I will take you through the process that we followed for changing the start page, the colors of the screens and the look of the buttons.

Today I will tell you about Step 1, the new Start Page for Uniface 9.7.

Step 1: The Start Page

Goal

A new start page that:

  • Is very different from the one that we have in Uniface 9.6 and earlier.
  • Leans towards the Windows 10 Metro theme

Challenges

While working toward the goal we found that there are a lot of functional details we needed to take care of, more that we initially expected from this screen. The other challenging aspects were the UI  and usability design.

Result

We went from this:

Startpage Old

To this:

Startpage New

The Workspaces

Instead of the Construction, Integration and Workflow workspaces we now have Mobile, Web, Desktop and Integration workspaces. We had to make a change here anyway because the Workflow workspace was not relevant anymore. This gave us the opportunity to better present the capabilities of Uniface.

Each workspace only shows a limited set of Editors, the ones we think are the most used in that workspace. All Editors are still accessible through the menus, in exactly the same way as before.

We have used the new Command Button properties that are available in Uniface 9.7 to make the big workspace buttons like tiles.

Startpage Workspace

For the fonts on the big workspace buttons and the editor buttons we created two fonts in the .ini file:

[screen]
IDFCategories=Microsoft Sans Serif,13,regular
IDFButtonText=Segoe UI,Western,8,bold

 

Of course we also changed the Presentation Preferences to reflect this change:

Startpage Presentation Preferences

And the Go To menu had to change as well:

Startpage Go To menu

Psst! I’ll let you in on a secret!

There is a way to customize the workspaces. It is not supported or documented, but we don’t mind if you play with it:

The file common\usys\startpage.def is an XML file that contains the definition of the start page. Since the file is tied to specific code in the development environment it is not fully customizable but you can use it to change the icons for the workspaces, and the Editors that are shown for a workspace. The icons are in the <BUTTONIMAGE> tag within the <CAT> tag. The Editors are in the <TYPES> tag within the <CAT> tag. You can choose from the editors that are defined in the <OBJTYPE> tags. For the Editors you can modify the icon, the name and the description. It is not possible to add new editors or workspaces.

The Shortcuts

The shortcuts are now presented in a grid. You can sort them on each column and you can search on the shortcut name. Please note that in the past there was different set of shortcuts per workspace, and there is now only set of shortcuts. There no longer is a limit to the number of shortcuts that you can have. The creation and handling of the shortcuts is unchanged.

Startpage Shortcuts

We used some new functionality of Uniface 9.7 to improve the presentation of the shortcuts. The colored area you see around the grid is an area frame. In Uniface 9.7 you can give an area frame a name and assign properties to it in the .ini file.  For details please see the uLibrary. For the cells of the grid and the search box above the grid we created logical widgets so they could be styled from the .ini file too. We used:

[areaframes]
SHORTCUTS=uframe(backcolor=#66B2E6;attach=hsize,vsize)[widgets] IDFSpeedSearch=ueditbox(font=editfont;onedit=T)
IDFTextCell=ueditbox(font=editfont)

 

Psst! I’ll let you in on a little secret!

We have hidden the logical widgets that we use in the IDF, so you don’t have to scroll through them every time you want to select a widget for your application. If you do want to see the logical widgets that start with IDF in the form painter in the development environment, put this in your .ini file:

[developer]
ShowFilteredWidgets = IDF

We do not guarantee that these widgets remain unchanged in future releases.

 

That’s it for now. Next post will be on how we changed the color of all IDF windows. Sounds simple hey?