Archive for the ‘Uncategorized’ category

5 Reasons Why Architecture Assessments Are Extremely Crucial for Software Projects.

A meticulous architecture assessment of a software system that is developed or yet to be developed helps in understanding if the team is on the right track to realizing the customer’s vision and business solution, not only at the present moment but from a futuristic long term perspective as well.

There are primarily 5 reasons why customers should carry out Architecture Assessments for their software systems. An architecture assessment helps in…

· Reinforcing the business vision and objective(of the architecture).

· Realizing the current state(of the architecture).

· Identifying unknown risks and addressing known problems.

· Defining the long term strategic roadmap.

· Realizing the ROI.

Reinforcing the objective

One of the most crucial reasons for an architecture assessment is to re-ensure that the objective or the goals of the architecture matches with the customer’s vision and business strategy. Many a time’s architectures that are created are based upon latest trends and best practices available in the market and don’t focus primarily on the non-functional requirements of the application. While it is definitely a good practice to make use of the latest trends and practices it is extremely important we ensure we don’t astray from the main objectives defined for the architecture.

Architecture is generally derived from the non-functional requirements and is designed to work in cohesion with functional requirements in order to achieve the overall business objective. The main goal of an architecture assessment is to ensure that we are on the right track to achieving the original objective of the architecture. For example: Every architecture has its own trade-off models, but every architecture should target a clear set of (non-functional)parameters that it should prioritize. It is important to prioritize between the architecture parameters viz: Performance, scalability, maintainability, reliability, extensibility. All parameters cannot have the same precedence else the architecture will be more of an overhead rather than a solution. This is the common cause of failures in most architecture’s. The architect loses sight of the end product and long term goals and comes up with something very fancy by implementing the latest principles which may be good but may not be applicable for that specific business instance and hence ends up overburdening the architecture.

During an architecture assessment phase the architect assess the prescribed architecture along with the NFR requirements and determines if the architecture has the right balance that will help sustain the business requirements, growth and vision of the customer.

Realizing the current state

This is one of the most important reasons for having an architecture assessment. It is very important to realize the current state of the architecture vis-a-vie the proposed state. Architecture assessments happen at different times of a project lifecycle. Ideally it should happen just before the start of design or before the start of development. However that may not be the case with most software projects due to timeline crunches and project pressures. Hence in most cases architecture assessments are done reactively to take care of a particular set of problems that has risen (during development/UAT/production) rather than preventing its occurrence in the first place itself. Examples are: Performance problems, maintainability problems, lack of scalability etc.

In real world projects we have architecture assessments done to address project complexities that are well into the development or during UAT phase. Sometimes it’s even done during the production phase on request of the customer due to a dis-satisfactory performance of the application. Hence it is imperative to take stock of the current architecture implementation, to understand the gap if any between the current architecture and the proposed architecture and to realize the current state and reason for the same.

80% of times the development architecture has more than 50% of deviation when compared with the proposed architecture. This is mostly due to the lack of well defined requirements, gap in understanding or lack in long term vision whilst finalizing the architecture during the proposal stage. Hence it is important to understand this deviation and the reason for the same, its root cause that warranted it and assess if we are on the right track or not. Many a times the deviations are warranted and at times it’s just due to timeline crunches and due to implementations of “work-arounds”. Whatever maybe the case it is imperative to assess the impact of the change with respect to the overall vision desired by the customer. This part of the assessment serves as the bases to derive the associated risks and plan of action for the same to ensure the architecture is put back on the right track.

Identifying unknown risks and addressing known problems

Once we have assessed the current state of the architecture we then need to identify the probable risks associated with it and address the known problems along the way as well. This is probably one of the most well-known reasons as to why an architecture assessment is requested in 60% of the cases. It is because the management suspect that there could be a lot hidden risks that have developed during the implementation phase of the project or because the project has numerous bugs during the testing phase. Unfortunately an architecture assessment at this stage is done to put in quick fixes to achieve a short term outcome. The long term suggestions at this stage are generally very costly to implement since it involves a substantial amount of re-work and hence may be ignored as long as the application is working “Today”.

These suggestions are generally ignored until the application deteriorates so much that it becomes practically useless and the customer would be forced to rewrite the application. Hence once the current state of the application is known it is extremely important to analyze this data effectively and identify the unknown risks as well as prepare a short term and long term roadmap to address the known problems. Sometimes customers and project teams are only interested in addressing the known problems but it is extremely important for the architect to state the importance of a long term solution over a short term fix. It becomes even more important in cases when existing state of the architecture has deviated considerably from the proposed state. It becomes a necessity to get the architecture back on track while simultaneously addressing the known problem areas as well. Only after we do this we can ensure that we have not deviated from the long term business vision of the customer.

Defining the long term strategic roadmap

This phase would not be required in cases where the implemented architecture doesn’t deviate from proposed architecture, since while proposing the architecture it is the duty of the architect to create an architecture with a long term vision and customer’s business objective. This phase however is almost always required since the implemented architecture almost always deviates from the proposed architecture for reasons mentioned above.

During this phase the architect reassess the original vision and analyses the current architecture to ascertain its deviation from the same. It is during this phase that the architect also addresses the pain areas and problems and creates a detail solution for the same. He also prepares a roadmap which contains corrective actions to ensure that along with addressing the known problems and mitigating the known/unknown risks he also puts in a detail technical plan to realign the architecture as per the original design and established standards.

Realizing the ROI

This is probably the most difficult thing to calculate as outcome of an architecture assessment but this is probably the most important outcome that an architecture assessment should generate. Customers invest in a lot of money in architectures hence it becomes absolutely necessary to verify they are getting value for their money invested. Many a times a lot of money gets invested in implementing the latest architectures in the market. As good as those architectures may be they may well have been intended to address a different set of problems. Hence applying a general set of latest architecture principles to target a wide range of problems is not really giving the customer value for money.

At the end of the architecture assessment it is extremely important to derive the value for money or tangible ROI the customer has received from the architecture prescribed, especially if the architecture assessment is being carried out post development or post production. In instances where the assessment is carried out before development then in those cases we would need to calculate the projected ROI the customer would be expected to receive. Giving tangible numbers to our customers is the only way to generate confidence in customers as well as it keep us architects in check from over prescribing fancy architectures which may not be aligning with customer’s vision.

An architecture should be crisp, focused and completely aligned with the customer business requirement and should be able to grow proportionally with the business. A good architecture contains the perfect balance of technical components that have been designed after prioritizing the non-functional requirements of the customer.

Conclusion

The article outlines the 5 most important reasons why customers and development teams should pro-actively carry out architecture assessments. In fact the cost of an architecture assessment should be budgeted for in the overall project cost. Ideally it’s good to have it done prior to the start of the development phase. However no matter in what stage it is carried out, it still provides a lot of value by adding stability and reinforcing long term business vision of the customer.

3 Types Of Web Application Architecture

Such terms as ”web app”, ”front-end architecture”, ”Web 2.0”, and ”HTML5 apps” have recently become trendy. Unfortunately these terms are often used in a misleading context which doesn’t consider the full specificity of implementation and usage of web app architecture. Today we’ll try to find out more about the types of web application architecture in the light of the latest web trends and key issues that matter to software owners.

We’ll outline 3 main types of web architecture and discuss their advantages and drawbacks for three points of view: software owner, software contractor (developer) and end user. There can be other types but they basically come down to these three as their subtypes.

First we’ll define a web application: it’s a client-server application – there is a browser (the client) and a web server. The logic of a web application is distributed among the server and the client, there’s a channel for information exchange, and the data is stored mainly on the server. Further details depend on the architecture: different ones distribute the logic in different ways. It can be placed on the server as well as on the client side.

It’s near to impossible to evaluate these completely different architectures impartially. But we’ll try to, using several criteria of evaluation:

User:
Responsiveness/Usability. Updates of data on pages, switching between pages (response time). Such qualities of user interface as richness and intuitiveness in use.
Linkability. Ability to save bookmarks and links to various sections of the website.
Offline work. Speaks for itself.

Developer:
Speed of development. Addition of new functional features, refactoring, parallelizing the development process between developers, layout designers, etc.
Performance. Maximum speed of response from the server with minimum consumption of computation power.
Scalability. Ability to increase computation power or disc space under increases in amounts of information and/or number of users. In case the allocated scalable system is used, one must provide data consistence, availability and partition tolerance (CAP theorem). It’s also worth noting that the case, when the number of features/screens of the client app is increased at the software owner’s request, depends on the framework and implementation rather than the type of web architecture.
Testability. Possibility and easiness of automated unit testing.

Software owner:
Functional extendability. Adding functionality within minimal time and budget.
SEO. Users must be able to find the application through any search engine.
Support. Expenses on app infrastructure – hardware, network infrastructure, maintenance staff.
Security. The software owner must be sure that both business data and information about users are kept secure. As the main security criterion we’ll consider the possibility of changes in functionality of app behavior on the client side, and all associated risks. Standard dangers are the same for the compared architectures. We do not consider security on the ‘server-client’ channel, because all these architectures are equally exposed to break-ins – this channel can be the same.
Conversion: site – mobile or desktop application. Possibility to publish the application on mobile markets or to make a desktop application out of it with minimal additional costs.

Some of these criteria might seem inaccurate, but the purpose of the article is not to show what’s good and what’s bad. It’s more of a detailed review that shows the possible options of choice.

Let’s outline three main types of web applications according to the roles performed by the server and the client browser.

Type 1: Server-side HTML

The most widespread architecture. The server generates HTML-content and sends it to the client as a full-fledged HTML-page. Sometimes this architecture is called ”Web 1.0”, since it was the first to appear and currently dominates the web.

Responsiveness/Usability: 1/5. The least optimal value among these architectures. It’s so because there is a great amount of data transferred between the server and the client. The user has to wait until the whole page reloads, responding to trivial actions, for example, when only a part of the page needs to be reloaded. UI templates on the client depend directly on the frameworks applied on the server. Due to the limitations of mobile internet and huge amounts of transferred data, this architecture is hardly applicable in the mobile segment. There are no means of sending instant data updates or changes in real time. If we consider the possibility of real-time updates via generation of ready chunks of content on the server side and updates of the client (through AJAX, WebSockets), plus design with partial changes of a page, we’ll go beyond this architecture.

Linkability: 5/5. The highest of the three, since it’s the easiest implementable. It’s due to the fact that by default one URL receives particular HTML-content on the server.

SEO: 5/5. Rather easily implemented, similarly to the previous criterion – the content is known beforehand.
Speed of development: 5/5. This is the oldest architecture, so it’s possible to choose any server language and framework for particular needs.

Scalability: 4/5. If we take a look at the generation of HTML, under the increasing load comes the moment when load balance will be needed. There’s a much more complicated situation with scaling databases, but this task is the same for these three architectures.

Performance: 3/5. Tightly bound to responsiveness and scalability in terms of traffic, speed etc. Performance is relatively low because a big amount of data must be transferred, containing HTML, design, and business data. Therefore it’s necessary to generate data for the whole page (not only for the changed business data), and all the accompanying information (such as design).

Testability: 4/5. The positive thing is that there’s no need in special tools, which support JavaScript interpretation, to test the front-end, and the content is static.

Security: 4/5. The application behavior logic is on the server side. However, data are transferred overtly, so a protected channel may be needed (which is basically a story of any architecture that concerns the server). All the security functionality is on the server side.

Conversion: site – mobile or desktop application: 0/5. In most cases it’s simply impossible. Rarely there’s an exception (more of exotics): for example, if the server is realized upon node.js, and there are no large databases; or if one utilizes third-party web services for data acquisition (however, it’s a more sophisticated variant of architecture). Thus one can wrap the application in node-webkit or analogous means.

Offline work: 2/5. Implemented with a manifest on the server, which is entered to HTML5 specifications. If the browser supports such a specification, all pages of the application will be cached: in case the connection is off, the user will see a cached page.

Type 2: JS generation widgets (AJAX)

Evolved architecture of the first type. The difference is that the page, which is displayed in the browser, consists of widgets (functionally independent units). Data are uploaded to these widgets through AJAX query from the server: either as a full-fledged chunk of HTML, or as JSON, and transforms (through JavaScript-templating/binding) into the content of the page. The option of uploading chunks of HTML excludes the necessity of using JavaScript-MV*-frameworks on the client side; in this case something simpler can be used – for example, jQuery. By lowering interactivity we boost the development speed and make functionality cheaper and more reliable.

The foremost advantage is that updates from the server arrive only for the part of the page requested by the client. It’s also good that widgets are separated functionally. A particular widget is in charge of a part of the page; changes in a part will not affect the whole page.

Responsiveness/Usability: 3/5. The volume of transferred data for a part of a page is smaller than for the whole page, that’s why responsiveness is higher. But since a page is a set of widgets, the applicable UI templates in a web application are limited by the chosen UI framework. Cold start (the first full loading) of such a page will take a little longer. The content, which is fully generated and cached on the server, can be instantly displayed on the client; here time is spent on getting the data for the widget and, as a rule, on templating. At the first visit the website will not be that quick to load, but further it will be much more pleasant in use, if compared to sites based on the architecture of the first type. Also it’s worth to mention the possibility of implementation of ”partial” loading (like it’s done on yahoo.com).

Linkability: 2/5. Here special tools and mechanisms are needed. As a rule, Hash-Bang mechanism is applied.
SEO: 2/5. There are special mechanisms for these tasks. For example, for promotion of websites based on this architecture it’s possible to predefine the list of promoted pages and make static URLs for them, without parameters and modificators.

Speed of development: 3/5. Not only does one need to know the server-side technologies, but also to use JavaScript frameworks on the client side. It’s also required to implement web services on the server side.

Performance: 4/5. The time and resources, spent on generation of HTML-content, are relatively minor if compared to the time spent by the app on retrieving data from the databases, and on their processing before templating. Use of the extended type of this architecture (when data are transferred as JSON) lowers the traffic between the client and the server, but adds an abstraction level to the application: retrieval from database -> data processing, serialization in JSON -> API: JSON -> parsing of JSON -> binding of data object on the client to HTML.

Scalability: 4/5. Same as for the first type of architecture.

Testability: 1/5. It’s required to test the server side, the client code, and the web service which returns the data to update widgets.

Security: 4/5. Part of the logic is shifted to the client JavaScript which can be modified by an intruder.

Conversion: site – mobile or desktop application: 0/5. Same as for the first type of architecture.

Offline work: 1/5. The manifest mechanism works in this case, but there’s a problem with updating or caching the data displayed on the widget. This functionality has to be implemented additionally: in the manifest can be indicated only names of the files which will be cached from the server. Correlation between the widget template file, cached in the manifest, and logic of page behavior requires extra labor efforts.

Type 3: Service-oriented single-page Web apps (Web 2.0, HTML5 apps)

Here we’d like to say that the term ”Web 2.0” isn’t quite correct here. One of peculiarities of Web 2.0 is the principle of involving users into filling and repeated adjustments of content. Basically the term ”Web 2.0” means projects and services which are actively developed and improved by users themselves: blogs, wikis, social networks. This means Web 2.0 isn’t bound to one technology or a set of technologies.

Let’s figure out the essence of this architecture. An HTML-page is downloaded from the server. This page is a container for JavaScript-code. This code adresses a particular web service and retrieves business data only. The data are used by JavaScript application, which generates the HTML-content of the page. This type of architecture is the evolution of the previous type, which actually is a self-sufficient and rather complex JavaScript application, where part of the functionality is shifted to the client side. To compare, the architecture of the second type cannot show a high number of interrelated and structured functions.

It’s also worth noting that nowadays rarely do appear JavaScript apps which work fully offline (with few exceptions, e.g. rad-js.com). This approach allows an easily made reverse conversion: publish an existing application on the web.

Responsiveness/Usability: 5/5. The volume of data transferred for updates, is minimal. That’s why responsiveness is at the highest level. UI is generated via JavaScript, it’s possible to implement any necessary variants. There is an issue with multithreading in JavaScript: in this particular case processing of big volumes of business data should be shifted to the web service.

Linkability: 1/5. One will need special tools and mechanisms, as well as frameworks which can use, for example, Hash-Bang mechanism.

SEO: 1/5. The hardest architecture to promote. If the whole app is promoted directly, there’s no problem: it’s possible to promote the application container. If it’s needed for a part of the application, a special mechanism will be needed for that purpose. Each more or less big search engine offers its own methods of standartization for this process.

Speed of development: 2/5. It’s required to develop a web service and apply more specialized JavaScript frameworks which build the app architecture. Since the architecture is relatively new, there aren’t many specialists who are able to create a high-quality site/system based on this approach. There aren’t many time-tested tools, frameworks and approaches.

Performance: 5/5. Under this architecture this criterion has the lowest influence from the server side. The server only has to give the JavaScript application to the browser. On the client side performance and browser type are of the biggest importance.

Scalability: 5/5. All the web logic is on the client side, there is no content generation on the server. When there’s an increase in the number of users, it’s required to scale only the web services that give the business data.

Testability: 3/5. It’s required to test web services and the client JavaScript code.

Security: 0/5. All the logic is shifted to the client JavaScript, which can be relatively easily modified by an intruder. For protected systems it’s required to develop a preventive architecture, which considers the peculiarities of open-source applications.

Conversion: site – mobile or desktop application: 5/5. A website becomes an application with the help of such platform as PhoneGap or similar ones.

Offline work: 5/5. This architecture is a full-fledged application; it’s possible to save separate data, as well as parts of the application using any storage (for example, localstorage). One more advantage is the possibility to switch data storage and management to the offline mode. To compare, the two aforementioned arhitectures are only partially functional in the offline. Here the missing data can be replaced with mocks, it’s possible to show alert windows or use data from the local storage, while synchronization may be left for later.

Thus we can see that there’s no perfect architecture – the optimal choice depends on tasks and priorities. If some criterion wasn’t mentioned here, it doesn’t mean it was ignored – it’s just the fact that for each particular software project every criterion has different importance. Each project must be discussed separately so the software owner will be able to make a choice. For every real project one of these criteria may be defining. It’s also possible to optimize the architecture of the app or implement a hybrid architecture which will perfectly meet the business requirements.

How to Find the Right Designer for Your Interior Design and Decorating Projects

Looking for an interior designer or interior decorator can be overwhelming if you are not sure which designer you need for the scope or your project. Are you building, renovating or moving and need professional advice? Are you planning to sell your property and not sure how to get ready for the first inspection?

This document gives you answers to frequently asked questions in regards to interior design, interior decorating, colour consulting and property styling.

It will help you finding the right designer for your interior design and decorating projects and eventually create your individual style in your home.

What is the difference between an interior designer and an interior stylist?

You may have asked yourself this question already when facing a building or renovation project. Do I need an interior designer, an interior decorator, a colour consultant or an interior stylist?

The answer is that it depends on the scope of the project.

An interior designer is a skilled professional who is designing interior environments according to your briefing. The interior designer either modifies what already exists (renovation) or provides an entirely new design for a space (new build). In this case the interior designer works closely with the architect and comes in at an early stage of the project. Interior designers work either along a team in design firm or on their own.

What is the job of an interior stylist? An interior stylist is a designer or consultant in a field subject to changes in style, especially fashion or interior decoration. An interior stylist cultivates or maintains any particular style and in most cases stylist are finders, keepers and collectors of beautiful objects.

The interior stylist can help you finding your own style, creating beautiful interiors that are unique and meaningful. This can be achieved with the simplest things and does not have to be expensive. The only thing you need to do is keep your eyes open to beautiful things in nature, architecture, design, museums, art, exhibitions, books, textiles and travel. There is only one rule: Only collect or buy things that mean something to you!

How does a colour consultation work?

The colour consultation focuses on creating a colour scheme for a specific room or space or the whole house according to your briefing. A qualified colour consultant can help you with interior and exterior colour schemes.

Prior to designing a colour scheme for you the colour consultant should always talk to you about the mood and atmosphere you would like to achieve in your space. He will explain to you the differences between the paint companies and their products and choose the right product for your needs. After designing the colour scheme you will receive a written recommendation including a specification sheet and brushouts ready for your painter to start.

Why is it important to seek advice from a designer when choosing colours?

Colour is the most powerful tool when it comes to non-verbal communication and the design element that makes a space come alive. Colour brings individuality in a space and it is one of the most useful tools to master when finding your own style.

Leatrice Eiseman, Executive Director of the Pantone Color Institute, says in her book Pantone Guide to Communicating with Color: “Among other uses, color stimulates and works synergistically with all of the senses, symbolizes abstract concepts and thoughts, expresses fantasy or wish fulfillment, recalls another time or place and produces an aesthetic or emotional response.”

When choosing a colour for a room or house it is important to think about the mood and atmosphere you would like to achieve. Is it a dark room or flooded with natural light? In which direction is the room facing? How are the proportions? Do you live in a small apartment or a contemporary newly built house with open plan living areas? All this needs to be considered when choosing colours for a space.

If you are overwhelmed by the choice of colours available – yes, there are thousands on the market – how can you start finding your personal colour scheme?

For some people it is a longer journey, for others it comes more naturally. The most important thing is to take some time, open your eyes, walk around your home and absorb the colour combinations you see. Then start gathering all the pieces you love. This can be anything from old porcelain, travel souvenirs, photographs, artwork, clothes, tear sheets from magazines, fabric swatches, stationary, a collection of stones, feathers or glass objects.

And don’t forget nature as inspiration for a colour scheme (interior or exterior). If you live near the ocean, shades of blues and greens can be used to link your interior with its surroundings. Flowers, butterflies, stones, shells, driftwood are fantastic inspirations for colour schemes.

Once you have gathered all your beloved treasures in one spot, play around with the pieces, group them by colours and you will see a colour palette emerge. This “moodboard” is a great starting point for your interior designer, interior stylist or colour consultant to help you creating an individual and personal space, a home that reflects who you are and a place that you love coming home to.

Stylist’s tip: Before you start painting always buy a test pot and paint a large sheet of paper or cardboard (one square metre) with your colour. Tape it to the walls in your room and study it for a couple of days. Look at it in daylight and artificial light. This is very important as colours change depending on the light, the orientation of the room, other colours in the room and spatial elements like furniture and artwork for example.

What is the difference between a colour and a styling consultation?

The colour consultation focuses on creating a colour scheme for a specific room or space or the whole house according to your briefing. A qualified colour consultant can help you with interior and exterior colour schemes.

The styling consultation focuses on creating a certain (Your) style in your home or simply on answering all your questions about colours, style, furniture sourcing and placement, art sourcing and placement, displays of your collections, accessories, proportions in a space, lighting etc.

Again it is vital that the designer listens to what you would like to achieve (briefing) and makes sure that he understood what you want (debriefing). Don’t let the interior designer or interior stylist talk you into something you don’t like!

How do I maximise the output of my styling consultation?

Are you planning to colour, redecorate or renovate, but don’t know where to start? Do you have lots of questions about colour schemes, furniture placement, how to display your collections, books or other beloved things? Are you not sure whether to redecorate with your old furniture and accessories or to renovate and create a new look? Do you need inspirations where to source furniture and accessories, second hand pieces or antiques?

If you prepare your first consultation with your stylist properly, you will get answers to all the questions you have. Here are my tips how to maximise the output from your styling or colour consultation:

• Be clear what you would like the outcome of the consultation to be.

• Decide which room or space you would like to focus on. Is it only one room or the whole house?

• Prepare yourself with tear sheets from interior design magazines like Real Living, Inside Out, Belle or Vogue Living. There are plenty on the market so choose the one that speaks to you most and start collecting pages of everything you like: colour schemes, furniture, accessories, room layouts, rugs, flooring, wallpaper, decorative items and everything that speaks to you. If you do this for a couple of weeks you will clearly see what you like and find your own personal style.

• Keep your eyes open to the beautiful things around you: nature, architecture, design, museums, art, exhibitions, books, textiles and travel.

• Make sure that your stylist is listening and explain what you want to achieve with your styling project, what you would like a room to do for you and what mood you would like to create in your space.

And finally one of the most important things: Don’t let the stylist talk you into something you don’t like! You have to live in the space and you need to feel comfortable and at home! It is all about creating your home with your personal touch.

How do I find my own style?

The answer is as simple as this: explore the world around you and appreciate the beauty that lies within everything you discover!

Keep your eyes open and your mind excited! Discover and appreciate the beauty that surrounds you every day! Find inspiration in nature, buildings, shops, exhibitions, museums, art, events, markets, magazines and of course books.

One of my favourite books I spotted in a museum shop is called: How to be an explorer of the world by Keri Smith. On the back it says: “At any given moment, no matter where you are, there are hundreds of things around you that are interesting and worth documenting.”

A stylist’s tip: always carry a little notebook and a pen with you in order to be able to sketch, doodle and write down what you discover.

Keep all your findings, notes and pictures in a folder or box and keep searching for at least four to eight weeks. Then start to group things by colour or theme and you will discover what your style is. And there are no rules. It is all about finding what you like!

Books for your inspiration

This is a list of books that I personally own and love! They are all a fantastic source of inspiration and creative ideas for your home.

Sibella Court: Bowerbird

Shannon Fricke: Sense of Style

Megan Morton: Home Love

Holly Becker: Decorate

Susanna Salk: Be Your Own Decorator

Geraldine James: Creative Walls

Hans Blomquist: The Natural Home

Is it necessary to seek advice from a stylist when I want to sell my property?

If you plan to sell your house it is worth investing in a styling consultation. A professional property stylist can help you to achieve maximum impact when presenting your home to potential buyers. A property stylist will help you to get ready for the first inspection by giving you advice on how to style your house with what you have. He will help you with colour schemes that attract potential buyers. He will also advice if you need rental furniture to style each room according to its function and help potential buyers to envisage themselves in the space. Property styling is all about creating a wow factor in key areas of your home and help the buyers to envisage themselves in your space. Once the styling is done don’t forget to book your stylist for the real estate photography shoot to make sure everything looks perfect on this day!