Category Archives: Design and Architecture

Guide to Building a Top UI Design Portfolio


Writer’s Note: This is the 2nd of a series of portfolio guides that aims to help those among our readers with the skill set that is featured.

Before We Begin

Professionals who work in the creative industry need portfolios to showcase their skills to attract clients and peers. Once upon a time this was solved by creating stunning printed pieces. However, no matter how you look at it, times have changed and designers are no longer just designers. We’ve got different specialties that cover many different fields within design. It’s important that you identify your strengths before starting to build your own portfolio.

Today we will cover all the bases that lead to the creation of an amazing User Interface Portfolio, so if this happens to be your specialization, keep reading!

Quality and Quantity

Take the creation of your portfolio as any other important project you would work on and start by picking the number of products or projects you would like to showcase. Think of a number that can cover all of what you can do from the point of view of a UI designer, that can be enough to represent you as the perfect candidate for the next big contract and not a lot to turn your portfolio into an overwhelming and never ending trip for your future clients. Edit your selection with a sharp eye, as you will be judged by your worst piece.

Picking up to 9 projects is more than enough to show a variety of pieces, however, if that would be too many for what you would like to show in your portfolio then don’t worry, as 6 is also an acceptable number of projects to offer.

We all know working on a portfolio can feel endless because it’s hard for us as designers to objectively select the best work. However, the sooner you publish your portfolio, the faster your work will be ready for potential clients to see. Set realistic deadlines for every step of the process: from the very beginning, to when you pick your projects, through to its publication.

What About the Target?

This will mainly depend on you: are you a UI designer focusing on gaming? How about a UI designer specialized in designing mobile apps? Maybe you do both plus more! Each of them has a different solution but these tips are applicable to all UI cases.

Benchmark

A little research has never truly hurt anyone and it’s useful to see what kinds of portfolios are out there, what trends you should avoid for your portfolio to not look the same as everyone else’s, and what details are definitely worth exploring to apply to your own presentation. Inspiration is your best friend when you’re starting to build something from scratch.

Awwwards is a good place to look for web-based portfolios and some users at Dribbble offer more on their profiles to a web portfolio than you might think.

Of course, learning from your fellow colleagues on Toptal is always a good idea, there are stunning portfolios out there for you to check out!

The Three Pillars

There are three things that should be kept in mind throughout the process of building a UI portfolio: remember the importance of the visuals, have a solid process and show the result of each project by telling a story. Be as specific as you want yet keep an equilibrium between all three of them.

While it’s important to pay attention to details and UI designers focus mainly on those, it’s vital for your pieces to be “more than just a pretty face.” UI designers mostly work with UX designers to achieve incredible products, or sometimes hybrid designers do both UX and UI at the same time. Therefore it’s key to keep the essence of your designs by having some storytelling on every single page and by dodging the commonly known “Dribbblisation of Design” which will differentiate you from regular designers.

Layouts & Styles

The recommended size for portfolios nowadays are:

  • A4 Horizontal, the width will benefit the amount of content you can show
  • Sizes that are always larger in width and no smaller than 1280x800px

Note: Most devices nowadays allow retina images which will make your images look sharper and better. Remember to upload them twice their original size with @2x.

When thinking of the kind of layout you should design for each product, keep in mind that most of your projects will be different and will have a particular style that makes them unique: this will help you with the previously mentioned storytelling. Start from beginning to end, or backward; the possibilities are endless as long as you keep coherence on every single page.

Think of the most eye-catching cover page for each project. Whether it’s the logo of the product with a color background, a mobile product displayed in a beautiful mockup, or the interface of a video game close up, all of them can work as long as you keep the visual noise to a minimum. Clients have only a few minutes per page to spare on your portfolio so it’s important to show and tell as much as possible in a clean and organized way.

Don’t be afraid to put two or three dispositive together for a cover page as it will show how adaptable and dynamic your product is and will also tell the client beforehand how much content they can expect from a project.

Be Meticulous

We live and breathe visuals so we can’t afford to have pixelated rounded corners on a mockup, different screen sizes or slightly different alignments for the same product.

Keep in mind:

  • The alignment of your mockups or screens should be the same as not to generate a slight jump between one page and another. Make sure to check alignments on Y and X.
  • Work with vector images. If you’re using Sketch, it’s quite handy to have mockups that can be scalable and will never look pixilated; use the “scale” option instead of manually scaling your mockup, as it will lose its shape. If you happen to be using Photoshop, on the other hand, scale your mockup and use Command + Z (or Control + Z on a PC) to go back and scale again, as every time you scale your image it will get more and more pixelated.
  • Check for details once you’re done with the general alignment of your objects by working with zoom. This will help you discard any lines or shapes that are slightly out of place.
  • If you’re using mockups for mobile or tablets, there are two ways to go regarding the top bar: if you wish to keep it, make sure the battery is on a 100% charge and that the carrier shows a real company, for example, AT&T, T-Mobile, Virgin, among others, because it will give a realistic touch to your product. If you wish to take the top bar away, mobile products usually look better in a rounded container with 2px of radius, without a mockup.
  • The background should always highlight the product you’re trying to show and not turn the client’s view away from it. There are two ways to go about this: 1. either use a plain color background that can make a friendly contrast with your product (keep in mind the mock up’s color and the color scheme of your design altogether) or 2. use a pattern or picture as background but get creative with its opacity and/or add a color layer on top with some transparency. Once again, the options are endless as long as the background is always secondary.
  • For web pages or landing pages, you can go ahead and divide them into three pages to allow for a smooth tour through each portion. Making it small and placing them into a single page would make the client miss key points and details that will differentiate your product from others.

The Process

It doesn’t matter whether you do UX, UI or a complete different specialization within design: it’s always important to show that your work had a process and that it didn’t just magically appear. Don’t be shy to include rough sketches, the good old technique of paper and pencil, collage or even photography that could have helped you in the thought process of building outstanding UI for your product.

Depending how you want to go to your portfolio, there are different ways and techniques to show these sketches:

  • The simplest method is to scan your sketches and make good use of Photoshop to handle levels, contrast, and brightness before using them in the correct size (not too big nor too small). Depending what you want to show with these sketches, they can all be on the same page spread everywhere or more organized, selecting just a few of the most polished ones.
  • If you got inspired by particular objects, taking photographs from above at a 90° angle would show the object in a real size and it’s a trend that’s been quite useful as of lately (be careful of any shadows over your object!). If your object isn’t as flattering at that angle, however, using non-conventional angles like diagonals could help give the photograph more movement.
  • Other tips regarding photography: 1. make sure the photograph is not blurry and that there aren’t other items creating noise or disturbing the general picture, and 2. consider properly cutting those objects and placing them over solid color backgrounds or alternatively create a scenario that serves as context. For both cases, do check contrasts, brightness, and levels as we don’t want it to be too bright or too dark.
  • Collages, paintings or experimentation over a paper with different items like brushes, pens or watercolor pencils can also be scanned or photographed. It mostly depends on what is important to show for each project, and what experiences are important for our client to have when they’re taking a look at those pages.

Storytelling

This is your work process and the way you show it will depend on what kind of projects you’ve worked on. If your main focus is iconography, showing rough sketches and a step-by-step process through to the final form are recommended. If you’re focusing on mobile products instead, screens that are connected to one another to show a feature can also tell a story, and initial sketches of the interface itself are always helpful as well.

Consistency and coherence are important to tell a story no matter how you want to show it. And even though each product will have its own unique style there is a rhythm that will guide your client’s eyes through each page.

Recap

To summarize everything, remember to:

  1. Keep in mind your target which will probably depend on your specialization as a UI Designer.
  2. Pick reasonable numbers of pages for your portfolio that can showcase the kind of professional you are.
  3. Do some benchmark; research has never hurt anyone.
  4. Set realistic deadlines, and treat your portfolio building as another project.
  5. Whatever you do, don’t forget about visuals, including written details and your work process. If there’s something a UI Designer can stand out in, it is by being quite meticulous with details.
  6. You live and breathe visuals but storytelling is just as important to differentiate you from regular designers who fall into the “Dribbblisation of Design” category.
  7. Be coherent and consistent with your style through every part of your portfolio.

Last but not least: have fun! Your portfolio, whether UI, UX or any other kind, should show not only how capable you are as a professional but also part of your personality and that you have a unique voice and style to offer.

Source: Toptal

Produce DWGs Like It’s 2016: Teigha For Architecture


In this article, I will introduce you to Teigha, a library that provides an alternative way of handling DWG files and ACA objects. We’ll write a small piece of code that creates a house out of ACA objects.

If you want to handle DWG files and AutoCAD objects programmatically, the only platform options areObjectARX and Teigha. All third-party components and applications that can read and write DWG files use Teigha as a base.

Produce DWGs Like It's 2016: Teigha For Architecture

Accelerate Your DWG Production With Teigha Architecture

Teigha Architecture is a set of libraries that enable you to read, write, and handle objects of the original AutoCAD and its derivatives like ACA. The libraries also provide many auxiliary mechanisms to help you handle AutoCAD objects and rendering devices to render the DWG database.

Teigha’s main features are:

  • Support DWG, DXF, BDXF, DGN file formats
  • Render drawing files using GDI, OpenGL, or DirectX with the ability to select entities.
  • Edit and manipulate CAD data programmatically, including:
  • Explode an entity into a set of simpler entities.
  • Apply a transformation to an entity.
  • Modify arbitrary properties of database objects.
  • Clone a database object.
  • Export to SVG, PDF, DWF, BMP, STL, DAE (Collada).
  • Import DWF/DAE/DGN files into a .dwg database.
  • Support custom objects — members can create custom objects that are usable within any Teigha host application (compatible with .dwg files only).
  • Support ACIS/Parasolid data internally, including rendering (wireframe and shaded) for embedded 3D solids and access to the underlying boundary representation data.
  • Implement custom commands.

Why Should Designers Consider Teigha?

AutoCAD saves its data to .dwg file format. DWG is a proprietary binary file format used for storing two and three-dimensional design data and metadata. DWG is an industrial standard. Thousands and thousands of DWG drawings exist and need to be supported. Besides AutoCAD, there is only one library which can load\save and manipulate objects stored as a DWG file: Teigha.

There are several reasons to use Teigha rather than AutoCAD ObjectARX:

  • Cost: If you develop an application that works with information stored as a .dwg file, you have two options: develop an AutoCAD plugin or develop your application based on Teigha. Developing AutoCAD plugin means that all of your customers have to own an AutoCAD license, which cost a fortune. Teigha pricing is very affordable.
  • Flexibility: Based on Teigha you can develop your own CAD application from scratch designed to fulfill your customer’s certain needs. You are not bound to AutoCAD core and GUI. You can develop your own particular GUI for your CAD application. Or, if you need a CAD-like GUI, you can use one of the Teigha-based cheap CAD applications available on the market ( like BricsCAD, ZWCad ) as a host to your plugin.
  • Many supported platforms: for example, you can build a standalone CAD application for Mobile platforms like IOS and Android, which is very demanded in certain areas.
  • Source code access: Teigha sources are available for founding members. If you need a specific functionality which is not provided or change existing functionality for your needs – you can buy Teigha sources and change anything you need.

Autodesk offers RealDWG – a software library that allows C++ and .NET developers to read and write AutoCAD® software DWG and DXF files. But again, it is much more expensive, has annual fees and provides only load\save functionality for DWG files, while Teigha provides rendering devices and other useful API for building your own CAD application.

Produce DWGs Like It's 2016: Teigha For Architecture

An Alternative to AutoCAD and ObjectARX

For starters, let’s load and render a DWG drawing. We can use the standard sample from Teigha’s distribution package:

Produce DWGs Like It's 2016: Teigha For Architecture

We’ve successfully loaded and rendered the DWG file. (By the way, the picture that you could see in the beginning of this article is the result of rendering a different file.) The standard sample is a windowed C++ application. It allows you to load, view, and edit DWG files without using AutoCAD. I should also mention that the API of AutoCAD objects is almost identical to the API of Teigha objects, so you can easily modify an existing ObjectARX plugin to support Teigha-based applications.

Most alternatives to AutoCAD, such as BricsCAD, ZWCad, and IntelliCAD, use Teigha to handle the DWG format and ACAD objects.

The Peculiarities of AutoCAD Architecture Objects

Now I will introduce you to architectural objects and how to handle them. AutoCAD Architecture handles special high-level objects intended for architectural design: walls, doors, windows, roofs, etc. The objects are viewport dependent, that is, they can be rendered differently depending on the camera direction. Objects are style based. A certain style is assigned to each object. If you change the style, all objects with that style will change. Every object consists of components, and every component has its own visual settings: color, line type, material, and scale. For example, a 3D door may consist of a frame, a door panel, and a sheet of glass. For different view modes, the object is rendered using different geometries, so the number and settings of components are different for different presentations.

Teigha for Architecture (TA)

To handle architectural objects, you can use ACA and its open API that enables you to create plugins. Alternatively, you can use Teigha for Architecture, a library developed by the Open Design Alliance.

Teigha Architecture is a С++ class library that implements all basic primitives of ACA, such as walls, windows, doors, roofs, beams, openings, etc. The library allows you to load these objects from any version of the DWG format and write (convert) to the latest DWG version. TA can render any primitives in different views and configurations. ACA objects interact with each other, so TA also supports ACA’s auxiliary classes and mechanisms, such as anchor, display manager, property sets, relation graph, etc.

Starting with Teigha Architecture API

I’ve already described Teigha’s main features. Let’s take a closer look at Teigha and write our first command, a very simple one. I’ll be using Visual Studio 2005, which is obviously outdated, but the Teigha libraries are multi-platform, and the distribution package includes a solution generator for all Visual Studio versions up to 2015. Depending on your license type, you will have access to the complete code of the whole library, or only to the pre-built binary files and header files.

The set of TA libraries looks like this:

Produce DWGs Like It's 2016: Teigha For Architecture

Basically, these are regular Windows DLL files (you can also build them for other platforms: iOS, Linux, UNIX, etc.). You can find LIB files for them in a separate folder. In addition to TA, we will need the Teigha Core libraries, because TA is an extension on top of the Core objects. Core implements the main mechanisms and objects of the original AutoCAD.

Initializing Тeigha Architecture

To initialize the library, we need a class that performs platform-specific operations on files.

class MyServices : public ExSystemServices, public ExHostAppServices
{
protected:
  ODRX_USING_HEAP_OPERATORS(ExSystemServices);
};

The distribution package includes two ready-made extensions for Windows, ExSystemServices and ExHostAppServices, which we can use in this case. Then we need to initialize the library and the graphics subsystem:

OdStaticRxObject<MyServices> svcs;
odInitialize( &svcs );
odgsInitialize();

_OdStaticRxObject_ adds the _addRef/Release_ logic to an object. The library saves the reference to the MyServices object and uses that object for platform-specific operations.

Let’s initialize the ТА libraries:

  // Loading of all public Teigha Architecture DRX modules.
        // Note that not all calls are necessary for some of them depend on others
        // but here we list all of them.
        //
        // If a program uses TD doesn't modify or create binary files
        // it may not load any of DRX modules on start because they will be loaded automatically. 
        // But if a program modifies or creates binary files then it is highly recommended
        // to load all DRX modules program uses.
        ::odrxDynamicLinker()->loadApp( OD_T("AecBase") );
        ::odrxDynamicLinker()->loadApp( OD_T("AecArchBase") );
        ::odrxDynamicLinker()->loadApp( OD_T("AecArchDACHBase") );
        ::odrxDynamicLinker()->loadApp( OD_T("AecScheduleData") );
        ::odrxDynamicLinker()->loadApp( OD_T("AecSchedule") );
        ::odrxDynamicLinker()->loadApp( OD_T("AecStructureBase") );

AecBase, AecArchBase, etc. are the TX modules (that is, DLL libraries) shown in the screenshot above. They have already been linked using LIB files, but that is not enough. We also need to initialize them as modules. What does it mean? At runtime, the memory contains a dictionary of loaded classes. The dictionary allows you to cast references between different types of TA objects and create instances of TA classes by using a centralized pseudo-constructor mechanism.

For example, when the command ::odrxDynamicLinker()->loadApp( OD_T("AecArchBase") ) is being executed, the function AECArchBase::initApp() will be called in the framework. Basically, initApp() will register all classes of the library in the global dictionary by calling the static function rxInit() for each of them:

…
AECDbSpaceBoundary::rxInit();
AECDbStair::rxInit();
AECDbWall::rxInit();
AECDbZone::rxInit();
…

After that, the object creation mechanism will be available. We will be able to create, for example, a wall by calling _AECDbWallPtr pWall = AECDbWall::CreateAECObject()_. Otherwise, an exception will be thrown if we try to create an object of the TA class.

Let’s create an empty DWG database by calling


OdDbDatabasePtr pDatabase = svcs.createDatabase();

This database is a central object. It is an object database that is saved to and loaded from a DWG file. We are going to add all architectural objects that we create to that database. When we are finished, we will save the database to a DWG file by calling:


OdWrFileBuf cBuffer( strFilename );
pDatabase->writeFile( &cBuffer, OdDb::kDwg, OdDb::kDHL_CURRENT );

Now let’s initialize some more loaded libraries and the display manager:


AECArchDACHBaseDatabase( pDatabase ).Init();
AECScheduleDatabase( pDatabase ).Init();
AECStructureBaseDatabase( pDatabase ).Init();
  
init_display_system( pDatabase );

An AEC dictionary is created in the database. That dictionary contains the default measurement units for length, area, volume, and angle, as well as print settings. Display representations implemented in the modules are registered.

The initialization is complete. If you have skipped some steps, the result will depend on which step you skipped: Objects will not be created or will not be rendered (you will see an empty screen), or there may be other glitches.

So far, the complete code looks as follows:


class MyServices : public ExSystemServices, public ExHostAppServices
{
protected:
  ODRX_USING_HEAP_OPERATORS(ExSystemServices);
};

int wmain(int argc, wchar_t* argv[])
{ 
  // Initialize TD with system services.
  // And create single instance of hostapp services
  // for TD database creation.
  OdStaticRxObject<MyServices> svcs;
  odInitialize( &svcs );
  odgsInitialize();


  // Loading of all public Teigha Architecture DRX modules.
  // Note that not all calls are necessary for some of them depend on others
  // but here we list all of them.
  //
  // If a program uses TD doesn't modify or create binary files
  // it may not load any of DRX modules on start because they will be loaded automatically. 
  // But if a program modifies or creates binary files then it is highly recommended
  // to load all DRX modules program uses.
  ::odrxDynamicLinker()->loadApp( OD_T("AecBase") );
  ::odrxDynamicLinker()->loadApp( OD_T("AecArchBase") );
  ::odrxDynamicLinker()->loadApp( OD_T("AecArchDACHBase") );
  ::odrxDynamicLinker()->loadApp( OD_T("AecScheduleData") );
  ::odrxDynamicLinker()->loadApp( OD_T("AecSchedule") );
  ::odrxDynamicLinker()->loadApp( OD_T("AecStructureBase") );

  // Create empty TD database.
  OdDbDatabasePtr pDatabase = svcs.createDatabase();;
  
  // Initialize database with default Teigha Architecture content.
  AECArchDACHBaseDatabase( pDatabase ).Init();
  AECScheduleDatabase( pDatabase ).Init();
  AECStructureBaseDatabase( pDatabase ).Init();


  init_display_system( pDatabase );

    
  // do something here with TA objects


  // Perform "zoom extents" on model space.
  {
    OdDbViewportTablePtr pVT =
      pDatabase->getViewportTableId().openObject( OdDb::kForRead );
    OdDbViewportTableRecordPtr pV =
      pVT->getActiveViewportId().openObject( OdDb::kForWrite );
    pV->zoomExtents();
  }

  OdWrFileBuf cBuffer( "H:\\TA_test.dwg" );
  pDatabase->writeFile( &cBuffer, OdDb::kDwg, OdDb::kDHL_CURRENT );
  
  odgsUninitialize();
  odUninitialize();

  return 0;
}

I’ve added the “zoom extents” command, so that when we open the created file, we can instantly see the objects added to it and the symmetrical deinitialization of the library. To make things simpler, I removed error checking and the try/catch constructs around the main actions.

Now the program will create an empty DWG file, which we can open and view in AutoCAD.

Handling objects

To show you how to work with the TA classes, I’m going to create a house consisting of a floor/foundation, walls, windows, a door, and a roof. Let’s begin with the walls.

For starters, we’ll add one wall to our drawing. To create the wall, we need to create a style for it first. Let’s write the add_wall_style function:


OdDbObjectId add_wall_style( OdDbDatabasePtr pDatabase )
{
  OdDbObjectId idResult =
    AECDbWallStyle::CreateAECObject( pDatabase, OD_T("Wall Style Created By Teigha(R) Architecture") );

  AECDbWallStylePtr pWallStyle =
    idResult.openObject( OdDb::kForWrite );

  pWallStyle->SetDescription( OD_T("Wall Style Description") );
  pWallStyle->SetDictRecordDescription( OD_T("Dialog caption") );

  pWallStyle->SetWallWidth( 4 );
  pWallStyle->SetWallWidthUsed( true );

  pWallStyle->SetBaseHeight( 110 );
  pWallStyle->SetBaseHeightUsed( true );

  pWallStyle->SetJustification( AECDefs::ewjLeft );
  pWallStyle->SetJustificationUsed( true );

  pWallStyle->SetAutomaticCleanups( true );
  pWallStyle->SetAutomaticCleanupsUsed( true );

  pWallStyle->SetCleanupRadius( 4 );
  pWallStyle->SetCleanupRadiusUsed( true );

  pWallStyle->SetFloorLineOffset( 3 );
  pWallStyle->SetFloorLineOffsetUsed( false );

  pWallStyle->SetRoofLineOffset( -3 );
  pWallStyle->SetRoofLineOffsetUsed( false );

  AECDisplayManager cDM( pDatabase );
  AECDbDispPropsWallModelPtr pOverrideModel =
    AECDbDispPropsWallModel::cast( pWallStyle->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepWallModel::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverrideModel.isNull() )
  {
    pOverrideModel->SetIsDisplayOpeningEndcaps( false );
    pOverrideModel->GetBoundaryCompByIndex( 0 )->SetColor( colorAt( 4 ) );
  }

  AECDbDispPropsWallPtr pOverridePlan =
    AECDbDispPropsWall::cast( pWallStyle->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepWallPlan::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverridePlan.isNull() )
  {
    pOverridePlan->GetBoundaryCompByIndex( 0 )->SetColor( colorAt( 4 ) );
  }

  return( pWallStyle->objectId() );
}

The function creates the AECDbWallStyle object and sets some of its parameters. Then it calls the display manager and changes the colors for the plan display representation (2D top view) and the model display representation (3D view).


AECDisplayManager cDM( pDatabase );
  AECDbDispPropsWallModelPtr pOverrideModel =
    AECDbDispPropsWallModel::cast( pWallStyle->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepWallModel::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverrideModel.isNull() )
  {
    pOverrideModel->SetIsDisplayOpeningEndcaps( false );
    pOverrideModel->GetBoundaryCompByIndex( 0 )->SetColor( colorAt( 2 ) );
  }

In this case, we’ve set the yellow color for the wall in the 3D view. It looks complicated, but there is a reason for that: The display representations and display manager mechanism in ACA work this way. The mechanism is flexible and has many capabilities, but its logic is not obvious and takes some learning on your part.

OdDbObjectId: The Runtime Reference

Database objects reference other database objects using ObjectId objects, and a database object pointer can always be obtained from a valid ObjectId objects. The effect of this mechanism is that database objects do not have to reside in memory unless they are explicitly being examined or modified by the user.

The user must explicitly open an object before reading or writing to it, and should release it when the operation is completed. This functionality allows Teigha to support partial loading of a database, where ObjectId objects exist for all objects in the database, but the actual database objects need not be loaded until they are accessed. It also allows database objects that are not in use to be swapped out of memory, and loaded back in when they are accessed.

If you need to preserve references to objects between program launches, use OdDbHandle.

For example, the add_wall_style function has returned idWallStyle. In this case, the style has just been created explicitly by calling AECDbWallStyle::CreateAECObject(), and idWallStyle contains the pointer to the actual object in the memory. To get write access to the style object, we need to perform this operation:


AECDbWallStylePtr pWallStyle = idResult.openObject( OdDb::kForWrite );

As a result, ‘openObject()’ will return the actual pointer to the object, which we can use.

Instead of the regular С++ pointers, the library uses the OdSmartPtr smart pointers:


typedef OdSmartPtr<AECDbWallStyle> AECDbWallStylePtr

The smart pointer’s destructor will notify the framework if the object has been closed. As a result, the related objects may be recalculated, notifications sent, etc.

Now we can add the wall by this call:


OdDbObjectId idWall1 = add_wall( pDatabase, idWallStyle, OdGePoint2d( 0,     0 ), OdGePoint2d(   0, 110 ) );

The add_wall Listing

OdDbObjectId add_wall( OdDbDatabasePtr pDatabase, const OdDbObjectId& idStyle,
                      const OdGePoint2d& ptStart, const OdGePoint2d& ptEnd, double dBulge = 0 )
{
  AECDbWallPtr pWall =
    AECDbWall::CreateAECObject( pDatabase->getModelSpaceId(), idStyle );

  pWall->Set( ptStart, ptEnd, dBulge );
  pWall->SetDescription( OD_T("A Wall") );

  return( pWall->objectId() );
}

As you can see, add_wall doesn’t do anything special. It simply creates the AECDbWall object with the style that we created earlier. The AECDbWall object is added to the model space of the database. In simple terms, the model space is a special dictionary that contains all objects to be rendered when we render the database.

Then the start point, the end point, and curvature are defined for the wall. Note that a wall doesn’t have to be flat. If you wish, you can make it convex.

If we did everything right, we will get a DWG file with one yellow rectangular wall. I’m using the code sample from the Teigha distribution package to view the file, but it will be rendered in exactly the same way in ACA.

Actually, I’ve manually rotated the camera in the 3D view. By default, you will have the top view.

Now let’s add 4 walls, including one convex wall:


OdDbObjectId idWall1 = add_wall( pDatabase, idWallStyle,
    OdGePoint2d( 0,     0 ), OdGePoint2d(   0, 110 ) );
  OdDbObjectId idWall2 = add_wall( pDatabase, idWallStyle,
    OdGePoint2d( 0,   110 ), OdGePoint2d( 110, 110 ) );
  OdDbObjectId idWall3 = add_wall( pDatabase, idWallStyle,
    OdGePoint2d( 110, 110 ), OdGePoint2d( 110,   0 ) );
  OdDbObjectId idWall4 = add_wall( pDatabase, idWallStyle,
    OdGePoint2d( 110,   0 ), OdGePoint2d(   0,   0 ), -1 );

We’ve got the basic structure of our house:

As you can see, the walls were not simply rendered as separate objects. Instead, smooth junctions were added automatically. It is one of TA’s automatic functions known as “cleanup.”

Adding windows

Now let’s add windows to our house. We can handle windows just like doors: We need to create a style for the windows that we want to add to the drawing, and then add the window objects with that style.


OdDbObjectId idWindowStyle =  add_window_style( pDatabase );

OdDbObjectId add_window_style( OdDbDatabasePtr pDatabase )
{
  OdDbObjectId idWStyle =
    AECDbWindowStyle::CreateAECObject( pDatabase, OD_T("Window Style Created By Teigha(R) Architecture") );

  AECDbWindowStylePtr pWindowStyle = idWStyle.openObject( OdDb::kForWrite );

  pWindowStyle->SetDescription( OD_T("Window Style Description") );
  pWindowStyle->SetDictRecordDescription( OD_T("Dialog caption") );
  pWindowStyle->SetAutoAdjustToWidthOfWall( true );
  pWindowStyle->SetFrameWidth( 2 );
  pWindowStyle->SetFrameDepth( 5 );
  pWindowStyle->SetSashWidth( 2 );
  pWindowStyle->SetSashDepth( 3 );
  pWindowStyle->SetGlassThickness( 1 );
  pWindowStyle->SetWindowType( AECDefs::ewtGlider );
  pWindowStyle->SetWindowShape( AECDefs::esRectangular );

  AECDisplayManager cDM( pDatabase );
  AECDbDispPropsWindowPtr pOverrideModel =
    AECDbDispPropsWindow::cast( pWindowStyle->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepWindowModel::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverrideModel.isNull() )
  {
    pOverrideModel->GetFrameComp()->SetColor( colorAt( 1 ) );
    pOverrideModel->GetSashComp()->SetColor( colorAt( 2 ) );
    pOverrideModel->GetGlassComp()->SetColor( colorAt( 3 ) );
  }

  AECDbDispPropsWindowPtr pOverridePlan =
    AECDbDispPropsWindow::cast( pWindowStyle->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepWindowPlan::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverridePlan.isNull() )
  {
    pOverridePlan->GetFrameComp()->SetColor( colorAt( 1 ) );
    pOverridePlan->GetSashComp()->SetColor( colorAt( 2 ) );
    pOverridePlan->GetGlassComp()->SetColor( colorAt( 3 ) );
  }

  return( pWindowStyle->objectId() );
}

As you can see in the code, the AECDbWindowStyle object is created and added to the database. Then some settings are set for the style (though we could have used the default ones). After that, colors for a few components are redefined for the 2D view and the 3D view. In this case, the components are physical parts of a window: a frame, a sash, and a sheet of glass.

Let’s add a window to the first wall by calling the add_window function:


OdDbObjectId idWindow01 = add_window( pDatabase, idWindowStyle, idWall1, 10, 10 );

// Inserts a window into a database using the specified window style.
// If idWall parameter is not null it also attaches the window to the wall.
// Returns Object ID of newly created window.
OdDbObjectId add_window( OdDbDatabasePtr pDatabase, const OdDbObjectId& idStyle, const OdDbObjectId& idWall,
                        double dOffsetAlongX, double dOffsetAlongZ )
{
  AECDbWindowPtr pWindow = AECDbWindow::CreateAECObject( pDatabase->getModelSpaceId(), idStyle );

  pWindow->SetRise( 10 );
  pWindow->SetWidth( 40 );
  pWindow->SetHeight( 40 );

  pWindow->SetOpenPercent( 60 );
  pWindow->SetMeasureTo( AECDefs::eomtOutsideFrame );
  pWindow->SetLeaf( 10 );

  if ( !idWall.isNull() )
  {
    pWindow->AttachWallAnchor( idWall );

    AECDbAnchorEntToCurvePtr pAnchor = pWindow->GetAnchor().openObject( OdDb::kForWrite );
    pAnchor->GetXParams()->SetOffset( dOffsetAlongX );       
    pAnchor->GetZParams()->SetOffset( dOffsetAlongZ );
  }

  return( pWindow->objectId() );
}

The add_window() function is similar to add_wall(), but there is a difference: It uses the anchor object.

We create the AECDbWindow object and add it to the model space of the database. Then we set some settings for that specific instance of AECDbWindow. After that, we put the window into the wall. A special object derived from AECDbAnchorEntToCurve attaches the window to the wall.

That object contains the offsets along the X, Y, and Z axes from the origin of the coordinate system of the wall to the origin of the coordinate system of the window. When we call AttachWallAnchor(), an instance of that object is created and added to the database. The wall itself doesn’t know if it has any windows. Creating an anchor involves another basic mechanism, the relation graph, which contains relations between objects: Who is attached to whom, who includes whom, and who owns whom. If you modify the wall, the relation graph will be notified that the AECDbWall object has changed. It will check all relations and trigger the updating of the related objects. In this case, AECDbWindow will be updated. For example, if you move the wall, the windows in it will move automatically, because they will be notified by the relation graph. You can get access to the relation graph and request relations for a specific object. Actually, a window knows to which object it is attached, because each window contains a reference to the anchor created.

Let’s take a look at the result:

I’ve changed the color of the walls so that you can see the window more clearly. (The code creates blue walls, I just picked colors while writing this article.) TA contains lots of predefined window styles and types, which you can use through enumeration:


enum WindowType
    {
        ewtPicture          =  1,
        ewtSingleHung       =  2,
        ewtDoubleHung       =  3,
        ewtAwningTransom    =  4,
        ewtDoubleCasement   =  5,
        ewtGlider           =  6,
        ewtHopperTransom    =  7,
        ewtPassThrough      =  8,
        ewtSingleCasement   =  9,
        ewtSingleHopper     = 10,
        ewtSingleAwning     = 11,
        ewtVerticalPivot    = 12,
        ewtHorizontalPivot  = 13,
        ewtUnevenSingleHung = 14,
        ewtUnevenDoubleHung = 15
    };
enum Shape
    {
        esRectangular       =  0,
        esRound             =  1,
        esHalfRound         =  2,
        esQuarterRound      =  3,
        esOval              =  4,
        esArch              =  5,
        esTrapezoid         =  6,
        esGothic            =  7,
        esIsoscelesTriangle =  8,
        esRightTriangle     =  9,
        esPeakPentagon      = 10,
        esOctagon           = 11,
        esHexagon           = 12,
        esCustom            = 13
    };

I’ve selected AECDefs::ewtGlider and AECDefs::esRectangular. As you can see, a lot of other shapes are available, too. By using these and other settings, you can create a very complex window type, with multiple sashes and an internal pattern on the glass sheets. The best thing is that you don’t have to create it piece by piece manually or implement everything programmatically. All you need to do is set a few parameters for the existing object or style.

Actually, all Teigha Architecture objects are pretty complex and have a lot of settings. Thanks to that, Teigha for Architecture provides massive opportunities “out of the box.”

Let’s add windows to all flat walls:


OdDbObjectId idWindow01 = add_window( pDatabase, idWindowStyle, idWall1, 10, 10 );
  OdDbObjectId idWindow02 = add_window( pDatabase, idWindowStyle, idWall1, 60, 10 );
  OdDbObjectId idWindow03 = add_window( pDatabase, idWindowStyle, idWall1, 10, 60 );
  OdDbObjectId idWindow04 = add_window( pDatabase, idWindowStyle, idWall1, 60, 60 );

  OdDbObjectId idWindow05 = add_window( pDatabase, idWindowStyle, idWall2, 10, 10 );
  OdDbObjectId idWindow06 = add_window( pDatabase, idWindowStyle, idWall2, 60, 10 );
  OdDbObjectId idWindow07 = add_window( pDatabase, idWindowStyle, idWall2, 10, 60 );
  OdDbObjectId idWindow08 = add_window( pDatabase, idWindowStyle, idWall2, 60, 60 );

  OdDbObjectId idWindow09 = add_window( pDatabase, idWindowStyle, idWall3, 10, 10 );
  OdDbObjectId idWindow10 = add_window( pDatabase, idWindowStyle, idWall3, 60, 10 );
  OdDbObjectId idWindow11 = add_window( pDatabase, idWindowStyle, idWall3, 10, 60 );
  OdDbObjectId idWindow12 = add_window( pDatabase, idWindowStyle, idWall3, 60, 60 );

I didn’t bother to complete the code, but you can handle each window separately: change its opening percentage, color, etc. If you change the style, the change will be applied to all windows with that style at once.

Adding doors to the drawing

To complete the picture, let’s add a door. First, we’ll create a 2D profile for the door panel (a door leaf with a window hole). Then we’ll create a style with that profile. Finally, we’ll be able to create door objects with that style. Alternatively, we could use the default styles. Just like windows (or any other openings), doors are attached to walls with an anchor. The add_profile_def, add_door_style, and add_door listing.


// Inserts profile definition into a database.
// Returns Object ID of newly created profile definition.
OdDbObjectId add_profile_def( OdDbDatabasePtr pDatabase )
{
  OdDbObjectId idProfDef =
    AECDbProfileDef::CreateAECObject( pDatabase, OD_T("Profile Definition Created By Teigha(R) Architecture") );

  AECDbProfileDefPtr pProfileDefinition = idProfDef.openObject( OdDb::kForWrite );

  AECGe::Profile2D cProfile;
  cProfile.resize( 2 );

  cProfile[ 0 ].appendVertex( OdGePoint2d( 0, 0 ) );
  cProfile[ 0 ].appendVertex( OdGePoint2d( 1, 0 ) );
  cProfile[ 0 ].appendVertex( OdGePoint2d( 1, 1 ) );
  cProfile[ 0 ].appendVertex( OdGePoint2d( 0, 1 ) );
  cProfile[ 0 ].setClosed();

  // Forces the contour to be counter-clockwise.
  // So if the contour is already ccw this call is not needed.
  cProfile[ 0 ].makeCCW();

  cProfile[ 1 ].appendVertex( OdGePoint2d( 0.2, 0.2 ) );
  cProfile[ 1 ].appendVertex( OdGePoint2d( 0.2, 0.8 ) );
  cProfile[ 1 ].appendVertex( OdGePoint2d( 0.8, 0.8 ) );
  cProfile[ 1 ].appendVertex( OdGePoint2d( 0.8, 0.2 ) );
  cProfile[ 1 ].setClosed();

  cProfile[ 1 ].makeCCW( false );

  pProfileDefinition->GetProfile()->Init( cProfile );

  return( pProfileDefinition->objectId() );
}

// Inserts a door style into a database.
// Returns Object ID of newly created door style.
OdDbObjectId add_door_style( OdDbDatabasePtr pDatabase, const OdDbObjectId& idProfile )
{
  OdDbObjectId idDoorStyle =
    AECDbDoorStyle::CreateAECObject( pDatabase, OD_T("Door Style Created By Teigha(R) Architecture") );
  AECDbDoorStylePtr pDoorStyle = idDoorStyle.openObject( OdDb::kForWrite );

  pDoorStyle->SetDescription( OD_T("Door Style Description") );
  pDoorStyle->SetDictRecordDescription( OD_T("Dialog caption") );
  pDoorStyle->SetAutoAdjustToWidthOfWall( true );
  pDoorStyle->SetFrameWidth( 2 );
  pDoorStyle->SetFrameDepth( 5 );
  pDoorStyle->SetStopWidth( 2 );
  pDoorStyle->SetStopDepth( 3 );
  pDoorStyle->SetShapeAndType( AECDefs::esCustom, AECDefs::edtSingle );
  pDoorStyle->SetProfile( idProfile );
  pDoorStyle->SetGlassThickness( 1 );

  AECDisplayManager cDM( pDatabase );
  AECDbDispPropsDoorPtr pOverrideModel =
    AECDbDispPropsDoor::cast( pDoorStyle->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepDoorModel::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverrideModel.isNull() )
  {
    pOverrideModel->GetPanelComp()->SetColor( colorAt( 1 ) );
    pOverrideModel->GetFrameComp()->SetColor( colorAt( 2 ) );
    pOverrideModel->GetStopComp()->SetColor( colorAt( 3 ) );
    pOverrideModel->GetSwingComp()->SetColor( colorAt( 4 ) );
    pOverrideModel->GetGlassComp()->SetColor( colorAt( 5 ) );
  }

  AECDbDispPropsDoorPtr pOverridePlan =
    AECDbDispPropsDoor::cast( pDoorStyle->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepDoorPlan::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverridePlan.isNull() )
  {
    pOverridePlan->GetPanelComp()->SetColor( colorAt( 1 ) );
    pOverridePlan->GetFrameComp()->SetColor( colorAt( 2 ) );
    pOverridePlan->GetStopComp()->SetColor( colorAt( 3 ) );
    pOverridePlan->GetSwingComp()->SetColor( colorAt( 4 ) );
    pOverridePlan->GetDirectionComp()->SetColor( colorAt( 5 ) );
  }

  return( pDoorStyle->objectId() );
}


// Inserts a door into a database using the specified door style.
// If idWall parameter is not null it also attaches the door to the wall.
// Returns Object ID of newly created door.
OdDbObjectId add_door( OdDbDatabasePtr pDatabase, const OdDbObjectId& idStyle, const OdDbObjectId& idWall,
                      double dOffsetAlongX, double dOffsetAlongZ )
{
  AECDbDoorPtr pDoor = AECDbDoor::CreateAECObject( pDatabase->getModelSpaceId(), idStyle );

  pDoor->SetRise( 10 );
  pDoor->SetWidth( 40 );
  pDoor->SetHeight( 50 );

  pDoor->SetOpenPercent( 20 );
  pDoor->SetMeasureTo( AECDefs::eomtOutsideFrame );
  pDoor->SetLeaf( 10 );

  if ( !idWall.isNull() )
  {
    pDoor->AttachWallAnchor( idWall );

    AECDbAnchorEntToCurvePtr pAnchor = pDoor->GetAnchor().openObject( OdDb::kForWrite );
    pAnchor->GetXParams()->SetOffset( dOffsetAlongX );
    pAnchor->GetZParams()->SetOffset( dOffsetAlongZ );
  }

  return( pDoor->objectId() );
}

Let’s add the following code to main:


AECDbWallPtr pWall = idWall4.openObject( OdDb::kForRead );
  double dLength = pWall->GetLength();
  double dOWidth = 40;
  double dL1 = 10;
  double dL3 = dLength - dOWidth - 10;
  double dL2 = dL1 + dOWidth + (dL3 - (dL1 + 2 * dOWidth)) / 2;

  OdDbObjectId idDoor     = add_door   ( pDatabase, idDoorStyle,   idWall4, dL2, 0  );

There is a difference, though: We open a wall with the read access and get its length in order to calculate the offset.

As a result, we’ve put a door in the convex wall:

Let’s also add windows to the convex wall:


OdDbObjectId idWindow13 = add_window ( pDatabase, idWindowStyle, idWall4, dL1, 10 );
  OdDbObjectId idWindow14 = add_window ( pDatabase, idWindowStyle, idWall4, dL3, 10 );
  OdDbObjectId idWindow15 = add_window ( pDatabase, idWindowStyle, idWall4, dL1, 60 );
  OdDbObjectId idWindow16 = add_window ( pDatabase, idWindowStyle, idWall4, dL2, 60 );
  OdDbObjectId idOpening  = add_window ( pDatabase, idWindowStyle, idWall4, dL3, 60 );

The result is a house without any roof or floor:

Let’s write the ‘add_roof()’ function.


void add_roof( OdDbDatabasePtr pDatabase )
{
  AECGe::Profile2D cProfile;
  cProfile.resize( 1 );
  cProfile.front().appendVertex( OdGePoint2d( 0,   0   )    );
  cProfile.front().appendVertex( OdGePoint2d( 0, 110   )    );
  cProfile.front().appendVertex( OdGePoint2d( 110, 110   )    );
  cProfile.front().appendVertex( OdGePoint2d( 110, 0 ), -1   );
  cProfile.front().setClosed();
  cProfile.front().makeCCW();
  
  AECDbRoofPtr pRoof =
    AECDbRoof::CreateAECObject( pDatabase->getModelSpaceId() );

  // Initialize roof profile.
  // By default all edges of Roof Profile have single slope of 45 degrees.
  pRoof->GetProfile()->Init( cProfile );

  pRoof->SetThickness( 2 );

  //// Manually modify Roof Segments.
  AECGeRingSubPtr pRoofLoop = pRoof->GetProfile()->GetRingByIndex( 0 );
  if ( !pRoofLoop.isNull() )
  {
    OdUInt32 i, iSize = pRoofLoop->GetSegmentCount();
    for ( i = 0; i < iSize; i++ )
    {
      AECGeRoofSegmentSubPtr pSeg = pRoofLoop->GetSegments()->GetAt( i );
      pSeg->SetFaceCount(1);
      pSeg->SetFaceHeightByIndex(0, 110);
      pSeg->SetBaseHeight(0);
      pSeg->SetOverhang(10.0);
      pSeg->SetFaceSlopeByIndex(0, OdaPI4);
      pSeg->SetSegmentCount(10);
    }
  }

  pRoof->setColorIndex( 3 );  
}

The roof is created based on a 2D profile whose direction of traversal is counterclockwise. Calling makeCCW()changes the direction of traversal if it was clockwise. It is important to do because the algorithm expects a profile whose direction of traversal is counterclockwise, otherwise it won’t work.

The profile coincides with the central line of the walls. Then we need to set the slope angle for each segment of the profile, the number of faces in the roof, the elevation (Z coordinate) of the top point of each face above the XY plane (SetFaceHeightByIndex), and the overhang. SetSegmentCount() works only with segments that have a curvature. This parameter sets the approximation accuracy, that is, the number of line segments that approximate an arc.

Here’s our roof:

There are lots of roof settings, so you can create a roof of almost any form: a gable roof, a hip roof, a hip-and-valley roof, you name it. Each face is a separate RoofSlab object which you can edit manually.

Adding a floor to the drawing

Now we need to add at least a very basic floor/foundation. To do it, we can use the slab object. Let’s write the add_slab function.

void add_slab( OdDbDatabasePtr pDatabase )
{
  OdDbObjectId idStyle =
    AECDbSlabStyle::GetAECObject( pDatabase, OD_T("Slab Style") );
  if ( idStyle.isNull() )
  {
    idStyle = AECDbSlabStyle::CreateAECObject( pDatabase, OD_T("Slab Style") );
  }

  AECDbSlabStylePtr pStyle =
    idStyle.openObject( OdDb::kForWrite );
  if ( !pStyle.isNull() )
  {
    pStyle->GetComponents()->Clear();

    AECSlabStyleCompPtr pCmp = AECSlabStyleComp::createObject();
    pCmp->SetName( OD_T("Base") );
    pCmp->GetPosition()->GetThickness()->SetUseBaseValue( false );
    pCmp->GetPosition()->GetThickness()->SetBaseValue( 6 );
    pCmp->GetPosition()->GetThicknessOffset()->SetUseBaseValue( false );
    pCmp->GetPosition()->GetThicknessOffset()->SetBaseValue( - 6 );
    pStyle->GetComponents()->Insert( pCmp );
  }

  AECDbSlabPtr pSlab =
    AECDbSlab::CreateAECObject( pDatabase->getModelSpaceId(), idStyle );

  {
    AECGe::Profile2D cBase;
    cBase.resize( 1 );
    cBase.front().appendVertex( OdGePoint2d( -5,   -5   ), 1 );
    cBase.front().appendVertex( OdGePoint2d( 115, -5   ) );
    cBase.front().appendVertex( OdGePoint2d( 115, 115 ) );
    cBase.front().appendVertex( OdGePoint2d( -5,   115 ) );
    cBase.front().setClosed();
    cBase.front().makeCCW();

    pSlab->GetSlabFace()->Init( cBase );
  }

  pSlab->SetThickness( 5 );

  pSlab->SetVerticalOffset( 0 );
  pSlab->SetHorizontalOffset( 0 );

  pSlab->SetPivotPoint( OdGePoint3d::kOrigin );

  AECDisplayManager cDM( pDatabase );
  AECDbDispPropsSlabPtr pOverrideModel =
    AECDbDispPropsSlab::cast( pSlab->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepSlabModel::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverrideModel.isNull() )
  {
    pOverrideModel->GetBoundaryCompByIndex( 0 )->SetColor( colorAt( 1 ) );
    pOverrideModel->GetBaselineComp()->SetColor( colorAt( 4 ) );
    pOverrideModel->GetPivotPointComp()->SetColor( colorAt( 5 ) );
    pOverrideModel->GetFasciaComp()->SetColor( colorAt( 6 ) );
    pOverrideModel->GetSoffitComp()->SetColor( colorAt( 7 ) );
    pOverrideModel->GetShrinkWrapBodyComp()->SetColor( colorAt( 8 ) );
  }

  AECDbDispPropsSlabPlanPtr pOverridePlan =
    AECDbDispPropsSlabPlan::cast( pSlab->OverrideDispProps(
    cDM.UpdateDisplayRepresentation( AECDbDispRepSlabPlan::desc() ) ).openObject( OdDb::kForWrite ) );
  if ( !pOverridePlan.isNull() )
  {
    pOverridePlan->SetIsOverrideCutPlane( false );
    pOverridePlan->GetHatchComp()->SetColor( colorAt( 1 ) );
    pOverridePlan->GetBelowCutPlaneBodyComp()->SetColor( colorAt( 2 ) );
    pOverridePlan->GetAboveCutPlaneBodyComp()->SetColor( colorAt( 3 ) );
    pOverridePlan->GetBelowCutPlaneOutlineComp()->SetColor( colorAt( 4 ) );
    pOverridePlan->GetAboveCutPlaneOutlineComp()->SetColor( colorAt( 5 ) );
  }
}

In this case, we create a new floor style, and then add components to it. A component is a floor piece that contains such parameters as thickness, elevation above the XY plane, name, material, index, etc. A floor can consist of several components with different settings. For example, if they have different elevations above the XY plane, you can use one floor object of that style to render all the floors and ceilings in a multistory building.

Style settings are applied to a specific object that contains the shape of the floor. In this case, we create a slab and initialize its profile with the same contour as the bottom part of the walls, only with a small offset at the edges. Then we use the display manager to redefine the colors of different components of the floor.

At last, we’ve created a house that looks like this:

Just to be sure, let’s try to load the resulting DWG file in Autodesk ACA:

That’s our house loaded in AutoCAD Architecture. It looks even better here, doesn’t it?

Conclusion

Using Teigha, we’ve created an empty database, initialized it for handling architectural objects, created a few commonly-used object types, and successfully saved all of them to a DWG file of the latest format.

Of course, I’ve simplified many things and described them in a cursory manner. But the purpose of this article is to demonstrate the capabilities of Teigha Architecture and give you a general idea of Teigha as an alternative solution for handling DWG files and AutoCAD objects.

This article was written by Aleksey Abramovsky, a Toptal C++ developer.

Who Knew Adobe CC Could Wireframe?


Wireframing is a major step in designing any user interface whether a website, application or software product. Without distraction in the form of visuals, colours, typography, styles and effects you can be more focused on defining content hierarchy and user experience.

Doing low fidelity wireframes and prototypes will help you test and iterate more often and in earlier phases, work faster and develop products that your users will love.

There are a lot of different wireframing tools to choose from in the wild. Which one you choose will depend on your personal preferences and workflow style.

Just like a lot of designers moving to digital design from the print world, I’m an expert in the Adobe applications like Illustrator, InDesign, and Photoshop. I can use them efficiently, everywhere and at any time (even if someone wakes me up in the middle of the night and refuses to give me a cup of coffee). However, these have also become the tools I use to do web and application visual design. So, for my workflow to be the most efficient I use them for wireframing too.

Who knew Adobe CC Could Wireframe

With every project, I usually start designing by doing very rough sketches on paper, or lately more often, if not near my office desk, on my iPad or smartphone screen. These sketches are there only to focus my thoughts regarding the chosen concept and the client will probably never see any of them. When I feel confident enough that my idea works, I jump right away into wireframing. I usually use Adobe Illustrator and InDesign combined. Illustrator for creating most of the UI kit elements and InDesign for wireframing itself.

In this article, I’ll explain a step by step process of how to incorporate those tools into your wireframing workflow as well. But, before I go into details, let me show you what the strengths and weaknesses are of using InDesign as a primary wireframing tool.

The Pros and Cons of Using Adobe InDesign as a Wireframe and Prototyping Tool

For some time now Adobe InDesign has been not only a desktop publishing application, but it’s also widely used for digital publishing and EPUB creation, and there are also some reasons why it is a suitable tool for wireframing too:

  • Master pages – You can quickly and consistently apply global design elements like navigation, headers, footers and so on. You can create as many master pages as you need, and on top of it, one master can be based on another.
  • Solid grid support – Allows you to create easily and apply different kinds of grids, complementing columns, horizontal and vertical guides to create modules, and subgrids for greater complexity and precision.
  • Alternate layouts – Enables wireframes for multiple devices and orientations in the same file.
  • CC Libraries – Give easy access and reuse different assets like commonly used objects, colours, character and paragraph styles. Create assets in InDesign, Illustrator, Photoshop or with the Adobe Capture mobile app, whichever you prefer.
  • Layers – Provide you the ability to organize, group, show/hide and lock/unlock objects and content selectively in the wireframe. Every page of a multi-page InDesign document has the same number and order of layers. All of the changes you make to layers are reflected on all pages, like visibility, stacking order or deletion.
  • Styles and tables – Give complete control over the look of your text, objects and tables through the use of InDesign styles. Styles can be based on each other providing the ability to cascade desired formatting easily throughout the document. Creation and formatting of tables that you can use as wireframe content elements or even helpers for layout purpose is very simple.
  • Typekit integration – In high fidelity mock-ups, you can use any of the Typekit fonts that sync to the desktop.
  • Interactivity and animations – You can use Adobe InDesign built-in interactivity and animation features to create different states of the web or application design for interaction. Most people use these features while creating magazines for Digital Publishing Solution and fixed layout EPUB export but they can be suited for prototyping as well.
  • Export options – InDesign can export the wireframes and prototypes you create in a variety of formats. Interactive PDF will probably be your format of choice in the majority of cases, but you can also use quite new Publish Online Feature to convert your document to interactive HTML that can be viewed in modern desktop and mobile browsers. Unfortunately, you don’t have any control over the export using Publish Online, and exported file is hosted on Adobe servers. You can share the prototype URL to your client, or embed it into your site. For more control and direct export to HTML5 you can use the in5 extension from Ajar Productions.

Adobe InDesign has many pros to be used as a wireframe and prototyping tool, but it also has some disadvantages:

  • Lack of predefined wireframe templates and elements – Since InDesign is not meant to be a wireframing tool, you have to create and prepare templates and object assets by yourself. (I’ll show you how to make that preparation step later in this article.) The good news is that most of this work will be done only once and after a few hours of work you’ll be ready to jump start your InDesign wireframing. Also, there are a lot of assets and wireframe kits that you can download from the internet, so there is no need to draw everything yourself.
  • Interactivity and animation features are limited and can be time-consuming – Although you can easily connect pages and add some interactivity and animations that process sometimes takes a long time. Some of the simple interactions can not be achieved simply, and you have to figure out how to do it. If you haven’t been using InDesign interactivity features yet, you’ll have a slight learning curve before you’ll be able to apply them efficiently.
  • InDesign documents can’t export directly as layered PSD files – If you do your visual design in Adobe Photoshop and want to have separated wireframe elements from building your design on, then you have to export your wireframes to PDF first, then open that PDF in Illustrator and export as layered PSD. People working on the Mac can also use a free script written by Rob Day to save InDesign files as a layered PSD.

Good Wireframe Preparation is Half of the Work

Start by fine tuning your working environment. If you do not already have a saved Workspace in Illustrator and InDesign for this kind of work, create one. In Illustrator start with predefined Web workspace and adapt it to your convenience: close panels you will not use often and open the ones you will, then rearrange them to suit your work style. When done, save the workspace by choosing Window > Workspace > New Workspace… Do the same thing in InDesign using Digital Publishing workspace as a starter.

Assembling Wireframe/Mockup/Prototype Kits

Efficient wireframing workflow using Illustrator and InDesign requests that you invest some time in making your user interface assets kit first. Since the introduction of Adobe Creative Cloud, CC Libraries are the best way for storing all your UI kits components.

You can create one or more Libraries for wireframing and prototyping purposes. For example, you can create one Library for websites wireframing, other for iOS application, third for Android applications and so on.

To create library Open Libraries panel and choose Create New Library from additional drop-down menu. Assets you put in libraries can be made and used in different Adobe desktop or mobile apps on all devices you log into with your Adobe ID. That means you can start with the project on your iPad or iPhone, continue on the desktop computer in the office and made last minute changes on home laptop with all the same assets available on all devices. If you work as a part of a larger team, library assets can be shared between team members and you can collaborate on them. Libraries can contain colours, graphics, layer styles (Photoshop only), paragraph and character styles. You add asset in library by clicking on the corresponding button at the bottom of CC Library panel with respective element selected. You can also add graphic assets by dragging them directly from your artboard to Libraries panel. Assets in libraries are organized by categories. To stick with good practices, rename each asset with meaningful name. Libraries are searchable, and finding an asset in a hip by typing beginning of it’s name will save you tons of time, especially when you have many different items in libraries. You can search only current or all libraries created. To change asset name just double click on it and type a new one.

Creating Kits Components

Although Adobe InDesign has some basic drawing tools that are pretty similar to Illustrator’s, Illustrator is a much better choice for drawing different kinds of elements in your wireframe. As a rule of thumb, make all kit elements that request some drawing beyond basic geometric shapes in Illustrator and simpler elements, that contain text you’ll need to change in layout, like simple buttons, in InDesign.

For starters, make a list of all the elements in the wireframe you’ll need, like navigation elements, page elements including images, video frames and text boxes, icons, avatars, form elements and all other interface elements. After your list is completed you can head to Illustrator and InDesign for elements creation. Start by creating a new document for wireframe or mockup kit components. Double-check that you choose either Web/Devices Profile in Illustrator or Web/Digital Publishing Intent from New Document dialog box, so pixels are used as units, and color mode is RGB.

Make wireframe kit assets as simple as possible, because they need to give fast visual cues for what they represent without been too much detailed. You should use very limited colour palettes of preferably a few shades of grey. Visually accentuate elements that are more important by coloring them with darker shades, or by giving them bigger contrast. For higher fidelity mockups or prototypes, you’ll create UI kits with more detailed elements that use each project’s respective color palette. For easy access to color palettes add them to CC Libraries too.

Who knew Adobe CC Could Wireframe

Adobe Illustrator assets in CC Libraries

Assets you add to Libraries from Illustrator are linked by default (since Adobe CC 2015). That means that when you modify a library asset in Illustrator, changes are reflected in all instances used. If you want to add unlinked asset to document press Option/Alt key while dragging it from the panel.

Who knew Adobe CC Could Wireframe

When you use linked Illustrator assets in InDesign they have little cloud icon in the upper left corner when document is viewed in Normal mode and they are all listed in Links panel. If you modify Library asset in Illustrator changes in the InDesign document won’t be done automatically. Cloud icon will be replaced with Modified Link exclamation mark icon, and you’ll have to update these links.

InDesign assets you place in InDesign document are not linked. That means that you can edit instances independently of the original, and when the original asset is modified those changes are not reflected on assets you already put into layout.

Who knew Adobe CC Could Wireframe

Use those properties when creating wireframes on your behalf: add assets to Library from Illustrator when you assume they’ll need to be modified and updated globally or add them from InDesign when you know you’ll want to modify them individually. Note that you can also make graphics in Illustrator and then Copy/Paste them to InDesign, modify if needed and then add to Library as InDesign asset.

If you happen to forgot which graphic asset is created by which application look at the right side of each item in Library panel while using Show items as a list preview more.

Adobe InDesign Flexibility with Texts

Since you’ll probably want to be able to easily change texts and its formatting create text based assets in InDesign. InDesign has a nice feature for filling text boxes with placeholder text. When you draw text box just make a right mouse click on it and choose Fill With Placeholder Text. You can easily add text box to Library like any other graphic element just by dragging. When you use those text assets later as a part of your wireframes layout you can modify text box itself or text it contains however you like.

Consider to make button UI elements in InDesign too. To create a button, make text frame first, type respective text in it and then use Object > Text Frame Options to define Inset spacing. Adjust Vertical Justification of text inside a box by choosing desired option from Align drop-down menu. Switch to Auto-Size tab and choose appropriate Auto-Sizing (that would probably be Width Only), and convenient reference point. If you do not want let InDesign break your text in more than a one line check No Line Breaks option.

Give Yourself a Hand

There are lot of Adobe Illustrator wireframing and prototyping UI kits available on the internet you can buy or even download for free if you want to fasten your wireframing preparation phase. Maybe you already have lot of those elements drawn that you can dig from your achieved projects. Open those documents, tweak any previously made elements if needed, and put them into respective Libraries.

If you are designing for a particular platform, for example iOS or an Android application be sure that you carefully read their human interface guidelines and use appropriate assets. Don’t put pressure on yourself that every asset possible has to be in your Libraries before you start with actual wireframing process because you can also add assets to your libraries later and on the go.

Creating InDesign Wireframe Templates

Who knew Adobe CC Could Wireframe

There is another important preparation step left that you also need to do: create InDesign templates you’ll use for making wireframes. Start by creating a new document with Web or Digital Publishing Intent and define appropriate page size for the screens you are designing for. Since it is recommended that you use some kind of a grid for laying out your wireframe elements set up the margins and create column grid by setting number of columns and the gutter space. You can change those settings later from Layout > Margins and Columns with respective master page (or pages) selected in Pages panel. If you need horizontal guides and complementary vertical guides, create them manually or make additional grid by using Layout > Create Guides… When creating grid you can help yourself with one of the online grid calculator tools like the Gridulator.

You can also create additional templates for presentation purposes with device mockup as a frame for your wireframes. Since one InDesign document can be placed into another, you can create wireframes in one InDesign document and then place it into another one for presentation purposes. Although it might seem complicated at first it is actually very simple and offers effective workflow. Keeping actual wireframe in separate document makes it easier to continue building from approved wireframes to polished visual design. On the other hand, you have presentation ready template to place wireframes into, add labels and comments and you are all set up to show your best to the client. When you make modifications on wireframe file just update it like any other link in presentation document, and ta-daaa! all changes are in your presentation too.

In the Layers panel you can prepare separate layers for different kind of the content: user interface elements, interactive features, gestures, labels or notes. If you’ll need more layers for a specific project you’ll be able to easily add them anytime during the wireframing process.

When you are done with creating save your templates as InDesign .indt template files. After all the templates you need are saved you are finally ready to start with wireframing efficiently.

Building Wireframes

First things first – start with the Master page. Drag all elements that will be the same on all screens of your project from Library. If you are designing website those are usually headers with logo and navigation and footer. Since you can make more than one Master page and they can be based on each other don’t forget to take advantage of that feature. For example, depending on the project, you can create a Master page for one website category, then make new Masters based on the first one and change on them only elements that need to be different for other categories you’re also having.

Who knew Adobe CC Could Wireframe

You can’t select, change or delete Master elements on regular document pages unless you click on them while holding Command/Control + Shift to override the master. Once your element is overridden you can change any of its parameters or completely delete it from layout. Keep in mind that even when you override the element, it’s parameters that you haven’t change are still dependent on the Master. For example, if you override an element and change it’s color, it’s size is still connected to Master’s and if you change it on Master page it will also be modified on that element you previously overrided. When inserting additional pages to your wireframing document remember to base them on the respective master. If you need to change the Master for pages already in layout, select them in Pages panel, make a right click and choose Apply Master to Pages… When you are finished with Masters, move along with pages for all screens of your project. Use Library assets and arrange them using Smart Guides and Align options to create final UI wireframe layout.

If you are making design for more than one screen size, make alternate layouts from Layouts > Create Alternate Layout or Pages panel. You can use liquid layout rules when creating alternate layouts to automatically or semi-automatically adopt page elements from one size and orientation to another or you can manually control them. For applying and testing Liquid Layout Rules use Page Tool or open panel: Window > Interactive > Liquid Layout.

Who knew Adobe CC Could Wireframe

Adding interactivity

Adobe InDesign has a bunch of interactivity features that you can take advantage of when creating wireframes or prototypes. Which features you’ll include depends on the final format you plan to save your wireframes, prototypes or presentation into. If you are exporting as PDF, interactivity is limited but you can at least make links between screens work. You’ll use Hyperlinks panel to create them. Select the item you want to behave as a link and click on New Hyperlink icon. From Link To drop down menu choose Page and enter desired page number. Repeat that action on all items you want to behave as links between the screens. You can also add hyperlinks to objects residing on the Master pages, and that can be a real time saver: create links on Master page once and they will work on all screens of your document.

Another interactive feature that you can use in interactive PDF format is button with Show/Hide action and that you can use to build all kinds of pop-up content.

You can create button from any graphic, text, image or a group. To create a button from a selected object use Window > Interactive > Buttons and Forms panel and click on the Convert to Button icon. Buttons can have different states created for Normal, Rollover and Click appearance. To add rollover or click state to button click on them in Buttons panel to activate and then edit button appearance for that state the way you want it to look. To add an action to a button, click on a plus sign and choose it from the list. Take into account that actions under SWF/EPUB will not work in interactive PDF. For creating popup elements choose Show/Hide Buttons and Forms. To hide buttons until triggered check Hidden Until Triggered option. You can include multistate objects in interactive PDF, but only if you export them as SWF first and then place those SWFs back in InDesign layout for PDF export. That workflow is tedious and those PDFs can not be properly seen in all PDF readers so you better avoid doing this unless really necessary.

If you want to convert your document to HTML prototype using InDesign CC 2015 Publish Online feature you can use much more interactive options like animations, multistate objects, multiple button actions, including all those intended for SWF/EPUB export.

You can add simple animations using Animation panel and choosing one of the built-in Presets from drop-down menu and setting its properties. One object can have only one animation applied, but if you need to add more of them, group your object with empty box and use the new animation on that newly created object. And repeat that few times if needed. For objects you need to show different states create multi state object. Create object for each state. Object can be a single element (picture, text box, graphic) or a group of different elements. Open Window > Interactive > Object States panel, select all objects you created for multi state object and click on the New button at the panel bottom. After your multi state object is made you’ll need to create buttons to go from one object state to another. Go To Next State or Go To Previous State actions reveal the specific object state with Go to State action.

If you want to have scrollable frame in your wireframe/prototype easiest way to create one is by usingUniversal Scrolling Frames extension from Ajar Productions. After you download and install extension you can use it as InDesign panel. For scrollable frame you’ll need to make content and one frame for container. Content can be text frame, picture, or more elements combined. If using more than one element as a content don’t forget to group them. When you are finished with making content and container box select the content and do Edit > Cut. Then select container and paste content inside by using Edit > Paste Into. Select container and using Universal Scrolling Frames adjust desired scroll direction.

By combining buttons, multistate objects, animations and scrollable frames you can achieve rich interactive experience.

To test interactivity in InDesign use EPUB Interactivity Preview panel. You can preview single page or whole document. Enlarge preview panel to your convenience.

If you haven’t being using Adobe InDesign interactive features yet be prepared that they have some learning curve, but with a little practice and few trial and error attempts you’ll quickly master them.

Exporting finished documents

When you are done with the wireframe and presentation file making all that is left is show your great ideas to the client in best way possible. For that purpose you’ll need to export your wireframes in one of the formats your client can preview. Although InDesign files can be exported in variety of formats you are probably going to use the most common Interactive PDF, or Publish Online feature if testing functional low or high fidelity prototypes. To save as interactive PDF choose Adobe PDF (Interactive) from Format drop-down menu in Export dialog box and adjust properties as needed. Do not forget to tick Forms and Media if there are interactive elements that you want to include. Clients can view PDF wireframes in free Adobe Reader and write all their comments in that same file.

You can also use PDF document you export from InDesign to create InVision (or some other tool that supports PDFs) prototype. If your standard prototyping tool, perhaps Marvel, can’t import PDF export your InDesign wireframe pages as JPEG or PNG images.

To export interactive HTML prototype that can be seen in modern browsers on different devices go to File > Publish Online or click on the Publish Online button from Application Bar. After the document is prepared to be published online and then uploaded you can copy document URL to share with all the stakeholders and start with reviewing process. You can also embed that published prototype on your site.

Downside of Publish Online feature is that it doesn’t have any additional control over the export and files are always stored at Adobe’s servers. Also it’s still preview feature and you can’t be sure in which direction Adobe is going to develop it or even discontinue.

Once your wireframe/prototype is exported it’s time for testing, reviewing and iterating process to start.

This article was written by  IVANA MILIČIĆ, a Toptal freelance designer.

How To Communicate The Value Of User Research


The beginning of a new project: Your client needs help with a redesign of its website or application.

“We want to improve the user experience, it has to be jaw-dropping for our customers, we want them to fall in love with our product.”

Here is the good news: Your client is aware of User Experience (UX), cares about customers’ needs and sees the value in investing in a great user experience. They asked for an expert with UX skills to help, but do theyreally understand what it means to deliver an exceptional user experience?

User research is a vital component of UX design. Don’t let anyone tell you otherwise.

User research is a vital component of UX design. Don’t let anyone tell you otherwise.

UX is more than a bunch of rules and heuristics that you follow in your product design process. UX is subjective, as the name suggests. It is the (subjective) experience that a user gets while using a product. Therefore, we have to understand the needs and goals of potential users (and those are unique for each product), their tasks, and context.

As a UX expert you should already be familiar with the maxim, It all starts with knowing the user.

Now for some bad news; this is the point when you discover your client’s misconceptions about UX.

UX expert: “Ok, let’s start with your users: Who are they? What do they do? What do they want? What are some of their pain points? I would like to talk to them, observe them, learn from them…”

Client: “Oh, we don’t need user research, that’s a waste of time.”

Wrong!

In this post I will try to explain why, and hopefully, help fellow UX specialists in their efforts to convince clients that good UX is next to impossible if it is not preceded by good user research.

No Need For User Research? There Is Always A Need For User Research

You cannot create a great user experience if you don’t know your users or their needs.

Don’t let anyone tell you differently. Don’t simply accept the common argument that there is no time or money to do any user research for your project.

User research should shape your product design and define guidelines that will enable you to make the right UX decisions.

User research should shape your product design and define guidelines that will enable you to make the right UX decisions.

User research will shape your product; it will define the guidelines for creating a product with a good experience. Not spending any time on research, and basing all of your design decisions on best guesses and assumptions, puts you at risk of not meeting your user needs.

This is how senior UX architect Jim Ross UXmatters sees it:

“Creating something without knowing users and their needs is a huge risk that often leads to a poorly designed solution and, ultimately, results in far higher costs and sometimes negative consequences.”

Lack Of User Research Can Lead To Negative Consequences

Skipping user research will often result in “featurities,” decisions that are driven by technical possibilities and not filtered by user goals.

“My wife would really enjoy this feature! Oh, and I heard from this person that they would like to be able to xyz, so let’s add it in there too.”

This leads to things such as overly complex dashboards in cars, where the user’s focus should be on driving, not on figuring out how to navigate an elaborate infotainment system.

Many users find automotive infotainment systems overly complex and distracting. Identifying the target audience is crucial to good UX design.

Many users find automotive infotainment systems overly complex and distracting. Identifying the target audience is crucial to good UX design.

Tesla’s cutting edge infotainment system, based on Nvidia Tegra hardware, employs two oversized displays, one of which replaces traditional dials, while the other one replaces the center console. Yes, it looks good, but it was designed with tech savvy users in mind. In other words, geeks will love it, but it’s clearly not for everyone. It works for Tesla and its target audience, but don’t expect to see such solutions in low-cost vehicles designed with different people in mind.

Poorly designed remote controls are not intuitive, so casual users tend find them overwhelming, resulting in a frustrating user experience.

Old remote controls are another example of hit and miss UX. There is little in the way of standardization, so each one takes time getting used to.

Old remote controls are another example of hit and miss UX. There is little in the way of standardization, so each one takes time getting used to.

But what about the purely digital user experience? Too many fields in a form, or too much information may overwhelm and drive your users away.

Poorly designed digital interfaces can drive users away. Even if they don’t, they will annoy users and feel like a waste time.

Poorly designed digital interfaces can drive users away. Even if they don’t, they will annoy users and feel like a waste time.

Instead of creating the opposite behaviour, poorly designed and implemented interfaces are more likely to scare off potential users.

Start User Research With Sources For Existing Information

Yes, user research will expand the timeline and it won’t come cheap, but both time and costs can be minimized. You can start with existing, and easy accessible, sources of information about user behaviour to gain a better understanding of user needs. These are:

  • Data Analytics
  • User Reviews and Ratings
  • Customer Support
  • Market Research
  • Usability Testing

Quality user research requires time and resources. However, you can start by using existing information to get a sense of what your users need.

Quality user research requires time and resources. However, you can start by using existing information to get a sense of what your users need.

Let’s take a closer look at each of these sources.

Data Analytics

If you are working with an existing product, your client might have some data and insights about its use. Data analytics assist with getting a good overview about general usage: How many visitors are coming to the website, what pages are most visited, where do visitors come from, when do they leave, how much time do they spend where, and so on.

But here is what this data is not telling you: How does the experience feel? What do users think about your service, and why are they spending time on your website? Why do they leave?

For example, your data indicates that users are spending a lot of time on a specific page. What it doesn’t tell you is why. It might be because the content is so interesting, which means users found what they were looking for. On the other hand, it could be an indication that users are looking for something they cannot find.

Data Analytics is a good starting point, but it needs further qualitative data to support the interpretation of the statistics.

User Reviews And Ratings

Your client’s product might have received some user feedback, already. There might be a section for feedback or ratings on the website itself, but external sources may be available as well. People might have talked about it in blog posts or discussion boards, users may have given app reviews in an app store. Check different sources to see what users are saying.

However, be aware of limitations. People tend to leave reviews and ratings about negative experiences. Don’t take this as a reason to shy away from user reviews or to ignore feedback!

“All these complainers… These aren’t the users we want, anyway!”

Instead, try to look for patterns and repetitive comments. Here are a few tips for making the most from user input:

  • Check whether any action has been taken on negative comments.
  • Compare the timing of negative comments to releases and changelogs. Even great apps can suffer from poor updates, leading to a lot of negative comments in the days following the update.
  • Do your best to weed out baseless comments posted by trolls.
  • What are users saying about the competition? Identify positive and negative differentiators.
  • Don’t place too much trust in “professional and independent” reviews because they can be anything but professional and independent.

User reviews are a good source for collecting information on recurrent problems and frustrations, but they won’t give you an entirely objective view of what users think about your product.

Customer Support

Your client might have a customer support hotline or salespeople who are in touch with the user base. This is a good resource to get a better understanding of what customers are struggling with, what kind of questions they have, what features/functionality they are missing.

Setting up a couple of quick interviews with call center agents, and even shadowing some of their calls, will allow you to collect helpful data without investing too much time or money.

Customer support provides you with a good opportunity to learn about potential areas for improvement, but you will have to dive in deeper to get detailed information about problems.

Market Research

Your client may have some basic information about the customer base, such as accurate demographic information, or a good understanding of different market segments. This information is valuable to understand some of the factors behind the buying decision.

It does not offer any information about the usage of the product, though.

Market research is a good source of information if you need a better understanding of how your client thinks, what their marketing goals are, and what their market looks like. However, it won’t reveal all relevant details about user goals or needs.

Usability Testing

If you are lucky, your client might have done some usability tests and gained insights about what users like or dislike about the product. This data will help you understand how people are using the product and what the current experience looks like.

It is not quantitative research, and therefore you won’t get any numbers and statistics, but it helps you identify major problems, and gives you a better understanding about howyour user group thinks.

There is also the option to do some quick remote testing session by using services such as usertesting.com.

Usability tests are another good way of identifying key problem areas in a product.

How To Educate Your Client About The Value Of User Research

The budget might be small and the timeline tight, but ignoring user research will eventually bite you. Help your clients avoid pitfalls by making them aware of the benefits of user research.

What’s the ROI of good user experience? Knowledgeable UX experts must be able to communicate the value of user research to clients.

What’s the ROI of good user experience? Knowledgeable UX experts must be able to communicate the value of user research to clients.

Here are some common arguments against user research and how to deal with them:

  • We don’t need user research. We trust in your skills as a UX expert

As a UX designer, you need to view user research as part of your toolkit, just like a hammer or saw for a craftsman. It helps you to apply your expertise in practice. No matter how much expertise you have as a designer, there is no generic solution for every problem. The solutions always depend on the user group and the environment, so they need to be defined and understood for every product.

User research will help get an unbiased view, to learn about users’ natural language, their knowledge and mental models, their life context.

You are the UX design expert, but you are not the user.

  • Just use best practices instead of research

Best practices originate from design decisions in a specific context; the digital industry is evolving at a rapid pace, design trends and recommendations change constantly, there is no fixed book of rules. We need to be able to adjust and adapt. Those decision should be made based on research, not practices employed by others, on different projects.

  • We already know everything about our users

Invite your client to a user needs discovery session to observe how users are using the product. Start with small tests and use remote usability testing tools such asusertesting.com to get some quick insights and videos of users in action.

The outcome might be a user journey map or a user task flow. Aim for a visualized document that identifies outstanding questions so you can define areas that need more research.

  • We have personas, we don’t need more research

Personas are a good tool for making your target group more tangible, and for becoming aware of different needs, key task flows and and how that might vary for different groups. It’s the common ground and a good starting point.

However, to redesign a product you need a better understanding of the usage. You need to know how people work with your product, what they do with it, when they get frustrated.

Ask for further details about user stories and task flows to make use of personas.

  • We don’t have the budget for it

The above list of sources for information about user behaviour should give you a good starting point for sharing ideas with your client on how to gain user information on a (very) tight budget.

Make your client aware of the risks if product design decisions are made without a good understanding of the user.

User Research Is The Basis Of Every Good User Experience

User experience is still a bit of a “mystery” in many circles: Everybody talks about it yet it is hard to define, as a good experience is in the eye of every user.

It is, therefore, key to gaining a sound understanding of the context, the user goals, and the thinking necessary for designing a truly exceptional user experience.

The more transparent you are with your work process, the better your client will understand your tools and the information you need to make good decisions.

While some clients may not be open to the idea of using additional resources on research, it’s necessary for experience specialists to explain the value of user research, and to argue for further research when necessary. To accomplish this, UX designers will require negotiating skills to make their case.

Luckily, proper user research is beneficial to clients and UX designers, so convincing clients to divert more resources towards research should be feasible in most situations. Reluctant clients may be swayed if you manage to devise a cost-effective user-research method, and I hope some of the tips and resources in this article will help boost user research, even if money is tight.

The original article was written by  FRAUKE SEEWALD, a Toptal web designer.

Are All Trends Worth It? Top 5 Most Common UX Mistakes That Designers Make


As web designers, we are constantly trying to create a great user experience and help users achieve their goals. In our daily work, we are using all kinds of common patterns and trends. In my experience, I have seen how those patterns and trends can easily steer both clients and designers/developers in the wrong direction. It’s no secret that from time to time we all get sidetracked with things that seem or look cool. I admit, I’ve fallen into those traps on plenty of occasions myself — I’ve opted to create something visually appealing and sacrificed the usability because of it. Why did I do it? I presumed a wow moment will happen and magically engage the user. I hoped this wow effect would make a long lasting impact. The sobering moment came when I found out my users had a hard time understanding the interface I had created and was proud of. Sometimes you learn the hard way.

Top 5 Common UX Design Mistakes

The lesson I learnt was that to avoid a bumpy ride for our users, we must always ask ourselves what is under the shiny surface of the user interface we are creating. It’s worthwhile to stop before embracing any patterns or trends and think about the value they provide. As Kate Rutter brilliantly said, “ugly but useful trumps pretty but pointless”.

Please don’t get me wrong — I am not suggesting we shouldn’t make things pretty — I am suggesting we should aim to make things usable and pretty. The key with patterns and trends is to find a balance between what looks nice and the value behind them.

In this article, I will list several common UX mistakes I see on a daily basis. While they are not all bad per se, they can be dangerous if not implemented with caution. I’ll also share some insight on how you can improve the usability when implementing those trends or even suggest an alternative solution. Without further ado, let us get on with the list.

Common Mistake #1: Large, Fixed Headers

We’re seeing more and more of tall, sticky headers — branding blocks and menus that have a fixed position and take up a significant amount of the viewport. They stay glued to the top and often block the content underneath them. I’ve seen headers on high-production websites that are over 150 pixels in height, but is there real value behind them? I might be pushing it a little bit, but large, fixed headers remind me of the dreaded and now ancient HTML frames. Yikes! Fixed elements can have real benefits, but please be careful when dealing with them — there are a number of important things to take into account. When implementing sticky headers, bear in mind a couple of common mistakes you want to try to avoid:

Too Large for Comfort

If the decision to design a large, fixed header has already been made, do some testing to find out if large is too large. Make sure not to go overboard and stuff the header with too much content, which will result in a super tall element. With the fixed header in place, browsing should still be comfortable and fast for your users. If you are having doubts about the sheer size of the header, try making it smaller without sacrificing too much of the visual appeal and brand presence. Failing to find a good balance could result in a somewhat claustrophobic experience for your users and leaving a small amount of room for the main content.

Last year, I have been working on a project where the client insisted on a sticky navigation bar on the desktop resolution. Even though the bar was not especially tall, I feared some users might get that claustrophobic feeling of being boxed in. My workaround was simple — by giving the nav bar a slight transparency using CSS, the users were able to see through the bar, which made the content area feel bigger. Here is that small piece of CSS code, so why not try and see if that works for you too.

.header { opacity: 0.9; }

Here is an example I found in the wild. Recently, I stumbled upon ATP’s player profile page on Roger Federer.

Its fixed header has a height of about 110px, and when you scroll down the page, a sub navigation appears, making the header 160px high. That is over 30% of the entire page height on my MacBook Pro with the dock open.

Not Fixing The Problem on Mobile

Granted, a lot of users will be using a huge screen, and sticky menus could be a plus on super big resolutions, but what about the smaller resolutions and the mobile world? Bear in mind that a significant portion of your users will be using a small resolution device, so for mobile, position: fixed is probably not the way to go. Thankfully, responsive techniques allows us to design a different solution and stick with the sticky for large resolutions only. The mobile-first approach will provide a lot of the answers — start with the mobile resolution, with only the essential content, and work your way up.

Coffee with a Cop also has a fixed header, but much smaller — less than 80 pixels.

This is arguably a good solution on large resolutions, as it enables quick and easy navigation. On small resolutions, the header is also fixed and takes up a considerable amount of the viewport. I would advise against a sticky header on mobile and suggest a sticky hamburger icon, which would open up a menu when tapped on. Although this pattern is not a universal problem solver, it does free up a significant amount of space. On smartphones and tablets, space can be precious.

Common Mistake #2: Thin Fonts

Thin fonts seem to be everywhere — numerous native mobile apps and modern websites. With screen technology advancing and rendering improving, a lot of designers are opting for thin (or light) fonts in their designs. They are elegant, fresh, and fashionable. However, thin type can cause usability problems. One of the main goals of any text is to be legible, and thin type can affect legibility in a major way. Keep in mind that not everyone will be using your website on a display that will render the thin type well. For instance, I have found thin type extremely difficult to read on my iPhone and iPad with Retina display. Before thinking about the look and feel of font, let’s step back for just a second.

If users can’t read the words in your app, it doesn’t matter how beautiful the typography is

From the Apple Human Interface Guidelines:

Above all, text must be legible. If users can’t read the words in your app, it doesn’t matter how beautiful the typography is.

Apple is referring to mobile apps, but the exact same principle applies to all websites. As Colm Roche said,legibility ≠ optional, but mandatory for good usability. There is no point putting content on a website if most of your users can barely read it, is there?

Here are some of the common mistakes you might want to bear in mind before putting your type on a diet:

Using Thin for Thin’s Sake

As with any trend, it is dangerous to use it simply because others are using it. Fonts should not only look good. First and foremost, they should be legible and provide a stepping stone to good usability. The decision to use thin type simply because of the fact that it looks good is bound to backfire. In his excellent talk More Perfect Typography, Tim Brown talks about a sweet spot at which a typeface sings. This sweet spot would be a combination of size, weight and color where you set the foundation of your website.

To make sure you have found a good body font and hit that sweet spot, do some testing in various environments. Which leads us to the next mistake worth avoiding:

Not Testing the Legibility on All Major Devices

Thin type may look good on your display and you may not have a hard time reading it, but be aware of the fact that you are not your user. Invest in usability testing to find out if your real users are happy with the typography on all major devices: desktop computers, laptops, tablets and smartphones. While doing mobile testing, have your participants use your website on mobile devices in daylight — your real users will not always have perfect browsing conditions. If you had to read something on a mobile device on a sunny day, you probably know how difficult it can be. If you decide to use a thin font on your website, there’s a simple way to adapt to mobile users. I will show a solution on a website I saw recently:

Oak does a fine job of adapting to the needs of the users — on the desktop resolution, their H1 heading has a very thin font weight. Since the heading is large and had a good color contrast, I suspect legibility does not suffer. On mobile, where the size of the heading is significantly smaller, the weight is slightly thicker, which surely aids legibility. Clearly, they have spotted legibility issues with thin fonts on small sizes and implemented a greater font weight through media queries. Their solution is simple, but very effective.

Common Mistake #3: Low Contrast

Low color contrast has become somewhat of a trend in user interface design in recent years. We have already covered thin fonts, which create a low type contrast, but there is much a bigger trap you can fall in — a combination of thin type with low color contrast will make yours truly really scratch his head and think have we lost our minds? Of course, not all low contrast is bad. It can even add to the visual appeal if designed with care. But as is the case with all UX mistakes, it is important not to go over the top and keep usability in mind.

A couple of major mistakes you might want to avoid while dealing with contrast are:

Low Color Contrast in Body Copy

While low color contrast is not exclusively bad, it can have quite a bad impact on the usability of your website and make text very hard to read for some of your users. If this article inspires you to increase color contrast on one thing only, make that your main body copy. It is most probably the least favorable area to experiment.

Cool Springs Financial uses a thin variant of Helvetica for body text. While it looks elegant and contributes to an aesthetically pleasing user interface, it is difficult to read on a number of platforms.

I did a quick test on a MacBook Pro with retina display, as well as an iPhone and an iPad with retina display. The screenshot is from my MacBook Pro which reveals contrast and legibility problems. I had a hard time reading the text on the website on all of my devices.

Not Testing the Contrast

Consider doing some user testing to avoid issues down the road. I already hear some of my clients and colleagues go “Bojan, user testing is time-consuming and expensive”. It can be, but it really does not take an awful lot to test the contrast on your website. Start with body copy and work your way up. There is a nifty tool called Colorable which will help you set a correct text contrast according to the WCAG accessibility guidelines. Once you know you are using correct text contrast, adjust other colors on your website and do quick user tests to make sure most of your users have a pain-free time. I doubt low contrast will cause a rebellion, but it could frustrate a lot of your users.

Common Mistake #4: Scroll Hijacking

Another trend we’re seeing a lot of is the scroll hijack. Websites that implement this trend take control of the scroll (usually with JavaScript) and override a basic function of the web browser. The user no longer has full control of the page scroll and is unable to predict its behavior, which can easily lead to confusion and frustration. It’s a risky experiment that could hurt the usability, so I advise great caution.

If you’re set on implementing a scroll hijack, you might want to try and avoid the following mistakes:

Using the Hijack Just Because It’s Trendy

Some websites can get away with scroll hijacking, but that is no guarantee your website can. Trends and patterns can’t be blindly followed and implemented. For example, we’re seeing many designers follow Apple’s presentational pages with scroll hijacking, parallax effects and high resolution images of various devices. Apple has their own reasons, their own users, a unique concept, and unique content. Since every website has unique problems, it also must have solutions tailored for those problems.

Not Testing on Actual Users

To avoid issues when borrowing ideas or patterns, make sure to test the prototype of your website on users. Simple usability testing will reveal whether the implementation of the scroll hijack is feasible or not. Testing will surely answer a lot of questions and provide clues on how you can improve upon your idea. Without testing, you have no way of knowing which way to go and developing websites based on assumptions are often costly in the long run.

Tumblr uses scroll hijacking on their current homepage. While their implementation could also be a risky one, it seems they understand their target audience, the content and concept supports it, and that they have addressed many of the user needs. When the user attempts to scroll down the page, the scroll is hijacked by the website, but the user is then quickly taken to the next section of the homepage. The content is broken into several sections or blocks, which are clear to distinguish and big indicator dots are fixed on the left side of the viewport. As a result, the homepage feels like a huge carousel you have control over, rather than an experimental website with a mind of its own.

Common Mistake #5: Ineffective Carousels

Carousels are very common on the web, and have been for a long time. While they can be effective, they can also turn into a nightmare if not designed and developed carefully. The nightmare for your users could be the fact that they are having difficulties understanding it. The nightmare for you could be the fact that your users are not seeing the important content in some of the slides of the carousel.

Carousels with no content of importance: not the most effective use of space on your website

Carousels with no content of importance: not the most effective use of space on your website

A lot of carousels I’m seeing have similar downsides. Some of those are:

Lack of Real Value for the Users

What is the real value the carousel offers to your users? If done right, a carousel should engage your users and help them achieve their goals quickly and pain-free. I often see carousels that do not provide additional value, but appear to be mere decoration. Here is a quick test you can do: take a post-it and write down three benefits of the carousel for the user. If you fail to think of three, there is a good chance your carousel needs more work.

Too many slides could have a negative effect on the users and they might simply choose to ignore the carousel. Usability guru Jakob Nielsen suggests the following:

Include five or fewer frames within the carousel, as it’s unlikely users will engage with more than that. While more than five could be too many, less than three could indicate a better solution is well-advised. One of the premises for a carousel is the fact that you need a lot of content fitted into a small amount of space, but with just two slides, why not show both slides at a time and forget about sliding altogether?

The previous and next Arrows and Slide Indicators Are Not Obvious and/or Accessible

Make sure you are making your precious content accessible. Important information in a carousel could remain hidden if the next and previous arrows are not obvious and large enough for a comfortable click. Oh, and do not forget the tap — your mobile users will thank you.

Sometimes, there are no arrows in a carousel, and the indicator dots are links for jumping between slides. Remember that you need to provide a nice, big clickable and tappable area (I recommend 35x35px at the very least). Otherwise, the small targets might lead to a very frustrating target practice and an exit from your website.

The Floresta Longo Foundation website has a carousel of images in the header. It has an autoplay and slides through five photographs. The previous and next arrows are small and are transparent which makes them both hard to spot and hard to click or tap. There are no indicators of the slide you are on and no labels showing what the photograph represents. The images are not links and act as a decoration. While the carousel may hold some value of engaging the user, it certainly leaves a lot to be desired.

Conclusion

I have listed several common UX mistakes in some of the current web trends. If you have implemented or are thinking about implementing any of them, I sincerely hope this article has provided something you will find useful. As a UX designer, use your best judgement and do not be afraid to improvise, but always remember to keep your users in mind.

Feel free to start a conversation below. I would love to read about your experiences, points of view, or suggestions on how to make things better.

The original article is from Toptal. Find more UX resources here.

Advantages of a separate DAO layer


With the arrival of ORM most of operations related to DB, like managing connections, transaction management have been abstracted to a certain extent and this has led to many people believe that we can directly call the entitymanager from service layer. I agree that we hardly change persistence layer ( atleast in services, for products its very much can be a valid scenario), But then can we overlook following advantages of DAO layer (All related to DRY)?

  1. Exception handling at a centralized location for all DAO issues -most of time service layer just pass on the failure to client and do not take any action. DAO can logg the exception, for example hibernate exception, log the query -these all can help dig the issue, and throw a runtime exception which will keep service layer code cleaner
  2. What if same query is being called from multiple location -even inside same service, for example “get list of all students”. A change in in this query, lets say an additional criteria, will have to be tracked across all occurence . If there is DAO, it will be delegated there and changes wil be at single place
  3. A well designed DAO layer can be used across projects -for example recently I wrote a DAO for JCR queries, and most of its part as create node, create heirarchical node, delete node etc were exposed in a manner that the lib was used across project
  4. We might not change the DB, but may be ORM itself need to be changed -for example one of client code which needed a deployment on Google apps had to change from hibernate to JPA (Google apps support JPA but not hibernate) -having a separate DAO made life simpler
  5. On flip side, this does introduce more layers and extra level of delegation, but I feel it’s worth it.

All UI elements should be disabled if not applicable


Was working on an flex based User Interface -SV team reported an issue that Till the time user has not filled all of the “Valid” details on the screen, the submit button remains should remain disabled.
I had purposely avoided this for following reasons

  • There is in field hint and tip available for each of input field to assist user
  • If users submit, there will be client side validation and any way wrong information cannot be submitted. Error can be more informative
  • Displaying error message as user types, this can be irritating
  • Why unnecessarily waste CPU cycle capturing keyboard events (Not a great point, but for listing sake ..)?

So a conflict between SV and Dev team –nothing unusual 🙂
Usability team was called in –and they mandated the SV objection, saying this has been done in some other products so I must comply…
Since it was more of my preference to avoid validation on key press, I gave in but would like to know how others think about this.

Resource bundle for dynamic content –server side or client side?


In fully RIA clients such as Flex, I got in taking a design decision –where to keep the names of the columns for a table, Server side resource bundle or Client Side resource bundle .
If number of columns is fixed, choice is rather simple –put it at client side. Having bundles at client side give flexibility to UI programmers to manipulate them as per business need.
But, Often we come across use case where the number of columns in a table are not predefined –they vary according to the result of business use cases executed. If there are fixed columns, resource bundle can stay at client side, challenge is when there are variable number of columns ..how to deal with that?
Approach 1: I prefer keeping it at server end, and passing an Array of “column display labels” which will be used to display the names of the columns, along with actual column names. UI programmer can blindly loop through the “Labels” array and generate column names.
Advantage: Varying of column names has no Impact on UI programmer, UI team blindly iterate through Array of labels.
Disadvantage: If a column name needs to be changed, UI programmer cannot handle it independently. It should be coordinated to server side team.
Approach 2: In second approach column names can be kept in a client side resource bundle.
Advantage: UI programmers can independently manipulate the names.
Disadvantage: UI programmer will have to maintain a list of “Master Columns”. At any point in time if business case warrants adding more column, UI team should be notified and changes made in client side Resource Bundle as well. This could result in real sync up issue.

Leveraging factory pattern for UI components in Flex


Using Factory method for UI components is always a good Idea. This helps adding common look/feel, validation etc. to a set of similar component at centralized place.
For example:

  • Text box for price input with custom requirement (as only two decimal places, in a given range, a custom look and feel etc.) can appear on multiple pages
  • Standard stuff as email entry boxes can have similar custom requirement

There are two approaches to deal with above

  1. One argument that most of validation is standard and out of box these day (Email, Date) while css and styling can be leveraged from a shared location, so these can be done “in place”. But greatest flip side I see that any change, say decimal precision from 2 places to 3, color change, background image change etc., will have to be tracked at multiple pages, even if just a reference change (CSS name, Validator name etc).
  2. Factory approach -I can have a method as
    UIElement getATextBoxWith2PlaceDecimal(){
    }
    

    This can encapsulate all validation and custom requirements.

I tend to use factory If I see repeatation on lot of pages -it seems to be a cleaner and maintainable approach.

How to handle metadata for UI screens representation


Case: There are multiple graphs to be displayed, depending on a few parameters selected by user graph type, its details and other UI related stuff vary a lot, what remains common is data.
Solution 1:
Create a UI screen for each type of representation, depending on parameter supplied by the user use a particular screen will be loaded
Pros: Very simple, Client is Dubm, each screen has a datasource which gets populated by data send by the server
Cons: Lot of duplication
Solution 2:
Keep metadata, say in XML or DB, about user selection and related UI representation. With help of this metadata prepare a value object containing all information for a graph to be plotted.
Pros: Generic solution, Very flexible
Cons: More coding needed, UI is metadata driven, if UI representation changes alot, this may not be the best approach, Client and server needs to be in contract –how to parse the Metadat, this is client is not that dumb.

What I have used:
I preferred second solution fro following reason:
1. In our team, UI development and Server side development is not segregated, hence having a Smart client is not an issue.
2. Represented metadata in XML and then used JAXB to get Object representation, with help of contract, a single class at client is driving the UI
3. No duplication, all changes are limited to either or all of 1.> Metadata XML, 2.> UI class (fulfilling the contract) or 3.> UI Screen