Posts tagged diagramming
Flowchart Symbols and their usage This is an overview of all the flowchart symbols that you will use when drawing flowcharts and process flow. All these objects are available in Creately and you can try out a demo or take a look at some sample flowcharts for more context. The terminator is used to show where your flow begins or ends. Ideally, you would use words like ‘Start’, ‘Begin’, ‘End’ inside the terminator object to make things more obvious. Flowchart Process object is used to illustrate a process, action or an operation. These are represented by rectangles; and the text in the rectangle mostly includes a verb. Examples include ‘Edit video’, ‘Try Again’, ‘Choose your Plan’. The Data object, often referred to as the I/O Shape shows the Inputs to and Outputs from a process. This takes the shape of a parallelogram. Decision object is represented as a Diamond. This object is always used in a process flow to as a question. And, the answer to the question determines the arrows coming out of the Diamond. This shape is quite unique with two arrows coming out of it. One from the bottom point corresponding to Yes or True and one from either the right/left point corresponding to No or False. The arrows should be always labelled to avoid confusion in the process flow. Document object is a rectangle with a wave-like base. This shape is used to represent a Document or Report in a process flow. This is a general data storage object used in the process flow as opposed to data which could be also stored on a hard drive, magnetic tape, memory card, of any other storage device. Direct Data object in a process flow represents information stored which can be accessed directly. This object represents a computer’s hard drive. This is an object which is commonly found in programming flowcharts to illustrate the information stored in memory, as opposed to on a file. This shape is often referred to as the magnetic core memory of early computers; or the random access memory (RAM) as we call it today. This object takes the shape of a reel of tape. It represents information stored in a sequence, such as data on a magnetic tape. This object is represented by rectangle with the top sloping up from left to right. The Manual Input object signifies an action where the user is prompted for information that must be manually input into a system. This shape takes two names - ‘Subroutine’ or ‘Predefined Process’. Its called a subroutine if you use this object in flowcharting a software program. This allows you to write one subroutine and call it as often as you like from anywhere in the code. The same object is also called a Predefined Process. This means the flowchart for the predefined process has to be already drawn, and you should reference the flowchart for more information.
Flowchart Symbols and their usage
This is an overview of all the flowchart symbols that you will use when drawing flowcharts and process flow. All these objects are available in Creately and you can try out a demo or take a look at some sample flowcharts for more context.
The terminator is used to show where your flow begins or ends. Ideally, you would use words like ‘Start’, ‘Begin’, ‘End’ inside the terminator object to make things more obvious.
Flowchart Process object is used to illustrate a process, action or an operation. These are represented by rectangles; and the text in the rectangle mostly includes a verb. Examples include ‘Edit video’, ‘Try Again’, ‘Choose your Plan’.
The Data object, often referred to as the I/O Shape shows the Inputs to and Outputs from a process. This takes the shape of a parallelogram.
Decision object is represented as a Diamond. This object is always used in a process flow to as a question. And, the answer to the question determines the arrows coming out of the Diamond. This shape is quite unique with two arrows coming out of it. One from the bottom point corresponding to Yes or True and one from either the right/left point corresponding to No or False. The arrows should be always labelled to avoid confusion in the process flow.
Document object is a rectangle with a wave-like base. This shape is used to represent a Document or Report in a process flow.
This is a general data storage object used in the process flow as opposed to data which could be also stored on a hard drive, magnetic tape, memory card, of any other storage device.
Direct Data object in a process flow represents information stored which can be accessed directly. This object represents a computer’s hard drive.
This is an object which is commonly found in programming flowcharts to illustrate the information stored in memory, as opposed to on a file. This shape is often referred to as the magnetic core memory of early computers; or the random access memory (RAM) as we call it today.
This object takes the shape of a reel of tape. It represents information stored in a sequence, such as data on a magnetic tape.
This object is represented by rectangle with the top sloping up from left to right. The Manual Input object signifies an action where the user is prompted for information that must be manually input into a system.
This shape takes two names - ‘Subroutine’ or ‘Predefined Process’. Its called a subroutine if you use this object in flowcharting a software program. This allows you to write one subroutine and call it as often as you like from anywhere in the code.
The same object is also called a Predefined Process. This means the flowchart for the predefined process has to be already drawn, and you should reference the flowchart for more information.
1. Color can be Used as a Differentiator
One of the main ways in which a color code can be utilized is for the purpose of differentiation. Consider an org chart, where (as an HR Manager) you want a split of the two sexes. Yourorganogram would look something like the example shown below.
As you can see, this is just a simple example. But colour can also be used to differentiate various things like office locations and hierarchy on an org chart, too. The use of color may be extended to various diagram types as well. For instance, consider using different colors to show what is a process and what is a decision in a flowchart.
2. Use Color to show Intensity
Color may also be used as an excellent barometer to show the difficulty or intensity that is present in certain tasks. For instance, if you are Project Manager who is tracking down a flowchart, you could use various colors to generate the difficulty of certain processes. A basic example is shown below.
We do agree that colour per se and color combinations are inherently subjective, yet you cannot deny the fact that it is certainly something that is important and can be widely used to offer a glut of benefits from easy assimilation of information to making diagrams look real beautiful. As always, we’d be thrilled with whatever response that you may have and would encourage you to make comments on this post and/or to get in touch with us if you got any queries.
We have a series of tutorial videos, but with the continuous developments and feature upgrades to Creately these tutorials look a tad bit outdated. So we thought of coming up with new tutorial videos to highlight some of the predominant updated features. Starting from this week, you can expect a series of video tutorials demonstrating how-to draw different kinds of diagrams with Creately.
Today, lets take a look at a simple 2-min how-to video on drawing professional Org Charts with Creately. With this, you will agree that creating Org Charts is seriously a simple affair.
We did this to help you understand some of the basic features. You can hit us back if you got any queries. We’re listening to you as always!
In keeping with that age-old cliche – a picture is worth a thousand words – we did a nifty visual timeline of the latest scandal (i.e. the News of the World saga) to hit global TV screens.
As you can see below, it’s way easier to explain things visually. Moreover, think of the numerous ways in which you can exploit various data sources and show information with more clarity via colorful mindmaps, wireframes, UML designs,Venn diagrams and flow charts among many others.
A few months back, we gave you a heap of informative articles on UML design that started with this. If you have not read it, we do urge you to do so since it does offer a nice introduction to class diagrams, which is the focus of this post. When it comes to system construction, a class diagram is the most widely used diagram. A class diagram generally consists of interfaces, classes, associations and collaborations. Such a diagram would illustrate the object-oriented view of a system, which is static in nature. The object orientation of a system is indicated by a class diagram.
In this post we’ll discuss the numerous guidelines that are present when it comes to class diagrams. But before we dig into the details of the guidelines, it makes sense to begin by highlighting the points that are going to be covered:
- General issues
- Aggregation and Composition
Due to the extensive nature of the subject, we thought it would be apt to break this down into two parts. In this specific post, we will indicate the guidelines that will relate to the areas of General Issues, Classes and Interfaces as has been mentioned above.
Since class diagrams are used for many different purposes, such as making stakeholders aware of requirements to highlighting your detailed design, you need to apply a different style in each circumstance. This section describes style guidelines that are relevant to various types of class diagrams.
1. Show visibility only on design models
2. Assess responsibilities on domain class diagrams
3. Highlight language-dependent visibility with property strings
4. Highlight types only on design models
5. Highlight types on analysis models only when the type is an actual requirement
1. Design class diagrams should reflect language naming conventions. In the “Analysis and design version of a class” image you see that the design version of the Order class uses names that conform to common Java programming conventions such as placementDateand calculateTaxes().
1. Model association classes on analysis diagrams. The image that shows the “Modelling association classes” indicates the association classes that are depicted as class attached via a dashed line to an association – the association line, the class, and the dashed line are considered one symbol in the UML.
2. Do not name associations that have association classes.
3. Center the dashed line of an association class.
A class is basically a template from which objects are created. Classes define attributes, information that are relevant to their instances, operations, and functionality that the objects support. Some of the more important guidelines pertinent to classes are listed down below.
2. Choose complete singular nouns over class names
3. Name operations with a strong verb
4. Name attributes with a domain-based noun
5. Do not model scaffolding code. Scaffolding code refers to the attributes and operations required to use basic functionality within your classes, such as the code required to implement relationships with other classes. The image above depicts the difference between the OrderItem class without scaffolding code
6. Never show classes with just two compartments
7. Label uncommon class compartments
8. Include an ellipsis ( … ) at the end of incomplete lists
9. List static operations/attributes before instance operations/attributes
10. List operations/attributes in decreasing visibility
11. For parameters that are objects, only list their type
12. Develop consistent method signatures
13. Avoid stereotypes implied by language naming conventions
14. Indicate exceptions in an operation’s property string. Exceptions can be indicated with a UML property string, an example of which is shown in the above image.
An interface can be defined as collection of operation signature and/or attribute definitions that ideally defines a cohesive set of behaviors. Interfaces are implemented, “realized” in UML parlance, by classes and components. In order to realize an interface, a class or component should use the operations and attributes that are defined by the interface. Any given class or component may use zero or more interfaces and one or more classes or components can use the same interface.
1. Interface definitions must reflect implementation language constraints. In the above image, you see that a standard class box has been used to define the interface PersistentObject (note the use of the «interface» stereotype).
2. Name interfaces according to language naming conventions
3. Apply “Lollipop” notation to indicate that a class realizes an interface
4. Define interfaces separately from your classes
5. Do not model the operations and attributes of an interface in your classes. In the above image, you’ll notice that the shipment class does not include the attributes or operations defined by the two interfaces that it realizes
6. Consider an interface to be a contract
It’s true that UML design is a vast and complicated subject that needs quite a bit of respect. While this whole subject may seem rather complex in nature, we have tried out best to simplify it, so that both professional software engineers and those who are just getting into UML design will find this whole post useful. As always, we are more than happy to field in any questions or doubts you may have. Till our concluding post, which we will release this week, keep those UML diagrams coming!
1. Know the difference between Vertical and Horizontal
A vertical organizational structure denotes a strict top down or bottom up structure. Typically, a rigid top down vertical organizational structure has been favored for businesses and other organization types. On the other hand, a horizontal organizational structure means a flat or semi- flat organizational structure, like a meritocracy. While many do design their Org Charts with their direct reports being positioned horizontally, the right thing to do is to be aware of what your company structure is all about, i.e. vertical or horizontal before actually attempting an Org Chart. A vertical Org Chart is shown below.
2. Name It and then Put a Face to It
Including images of staff in your Org Chart can help humanize your company intranet site, assist new employees get better acquainted, and help virtual teams that are not in close proximity to get a sense of who their co-workers are. But you really need not limit yourself to just staff pictures. If you do have an Org Chart that is rather mundane and abstract, you could infuse some liveliness and color to it but plugging in some images to highlight the type of operations as well. For instance, if you have a department called Division of Finance & Management, you could have a dollar sign image next to it. Check out how big a difference, having a picture and not having one makes below.
3. Go Unconventional with Org Charts
While Org Charts are conventionally used by HR to show the basic structure that is present in an organization, why not use such a diagram type to illustrate other types of information? For instance, you could use Color to showcase the gender balance or the different age groups present in an organization. Don’t stop there though, you could even use a colorful Org Chart to allocate staff members into different teams in the Sports Committee, to assess the number of Senior Executives present as opposed to Junior Executives or even. There really is no limit as to what you can do with organigrams, all it takes is some intuition and creativity.
Stick to these 3 tips to make your designs clear, sharp, clutter-free and offer more information. Try out these smart 3 tips on Creately for free and see how creating Org Charts is as easy as peanuts.
Additionally, we got some great news for all our Creately for Fogbugz users. You can now renew your 1-year maintenance license by logging in with your existing account and extending your maintenance here. This license will allow you to enjoy a year’s worth of cool new upgrades for a nominal fee.
Indeed, things like bug fixes, new releases and updates may have kept the Creately team busy this past week but the truth is it has been a slow couple of days due to the celebration of Wesak in our R&D office in Sri Lanka. Taking some time off, the development boys and girls decked the office with colorful lanterns that are intrinsic to such an important religious festival.
As this week winds down, make sure that you stick to this space since the next few posts will focus on Sitemaps and some best practices related to it. Additionally, we just launched our Flowchart Minisite and Wireframe Ministe, so this is definitely a repository of valuable information that you should take a peek at. Stay tuned, more diagramming joy comes your way soon!
From flowcharts to UML diagrams, we’ve offered quite a bit of important reading material for you out there. Our last post focused on wireframes and this present one also revolves around this really useful tool. To start things off we thought we’d focus a bit on the uses and benefits of wireframes.
You see, for the layman, the topic of wireframes may relate to just web designers and software developers. However, the fact of the matter is that wireframes are actually used by a variety of disciplines. While the main functionality of wireframes depends on the profession per se, find below some of the professions that utilize wireframes the most and how it benefits them.
- Developers would use a wireframe to understand the functionality of a particular site
- Designers would use a wireframe to push the user interface process
- Information architects would utilize wireframes to illustrate the navigation paths that is present between pages
- Business stakeholders would use wireframes to make sure that objectives and requirements are met via the design
Choosing to work with wireframes will lead to a collaborative effort since it helps link the information architecture to the visual design. Conflicts are sure to take place among these professional roles, as wireframing is a controversial part of the design process. Since wireframes signify an aesthetic that is very minimal, it is hard for designers to see how close the wireframe needs to depict actual screen layouts. Another difficulty with wireframes is that they don’t effectively display interactive details.
Generally speaking, wireframes usually have different levels of detail and may be split into two categories to show how closely they resemble the end product (this is also known as fidelity).
Wireframes that are Low-fidelity
Ideally low-fidelity wireframes (more like a quick mock-up) possess less detail and consume less time to produce. Additionally, these wireframes assist a project team to share effectively since they are usually abstract, with the use of rectangles and labelling to provide content. These wireframes are easy to identify with dummy content or symbolic content utilized to represent data when there is a lack of real content being available. For simple or low-fidelity drawings, paper prototyping is a common technique. Since these sketches are just representations, annotations—adjacent notes to explain behavior–are useful. However, online wire framing provides added benefits such as collaboration across distances, versioning and publishing for the next stage.
Wireframes that are High-fidelity
Then there are also high-fidelity wireframes. These are used for documenting, since they incorporate a level of detail that is very close to the design of the actual webpage or application, thus taking longer to create. With high fidelity wireframes, it is far easier to engage the client of a project since you are showing something that is close to the finished product. As mentioned previously, high fidelity wireframes gives a lot of priority to documenting. Needless to say, documenting is very significant since it is very important to communicate clearly with the next stage of a project. This would offer many benefits like reducing the chances of having to do re-work and also reducing time and money wastage.
We hope this gives you some useful insights into wireframes. However, there is more to come next week, with the focus once again being on wireframes and UI mockups, so stay tuned to this space. As always, you are more than welcome to give us a shout or to leave a comment below this post. Till next time – Happy Diagramming!
We just finished with Part 1, Part 2 and Part 3 on the basics of UML diagramming. We now have a two-part series on Flowcharts. This is a very straightforward post, which you will find useful when it comes to getting your diagrams picture perfect. When it comes to flowcharts, one of the most significant things to consider is the element of clarity and attention to detail. Flowcharts, as we all know, can range from solving simple to complex problems. However, there is a list of common mistakes that are relevant to any flowchart, which you should be cautious of.
Every symbol has a meaning. While it may seem convenient to use a process symbol for everything, this could end up confusing the reader. To get a better understanding of what symbols are relevant when, read up on what each object is all about.
2. Avoid flow direction that is inconsistent
The two most widely accepted flow directions are top to bottom or left to right. Having said that these two types of directions should not be mixed into the same flowchart. Consistency really does matter.
3. Excessive color schemes
Your flowchart is designed to give a solution to a problem. With this in mind, the last thing you want to do is to have your message lost in visual noise.
4. Symbol sizes should be consistent
Maintaining a flowchart that is well proportioned is vital when it comes to avoiding a visual mess. As a rule of thumb, ensure that the height and width are in proportion to each other and the rest of the symbols in the flowchart. This is not, however, applicable to objects that are meant to be intentionally small, like connectors.
5. The need for consistent branch direction
In a perfect world, a flowchart should be logical in all aspects. One of the areas that we do not pay much heed to is branch direction. The best example to illustrate this point is with Decision symbols. Ideally, TRUE conditions should flow out from the bottom while FALSE conditions should flow out from the right side.
6. Flowchart symbols and spacing
More often than not we choose to ignore this crucial point. To make your flowchart more professional you should maintain even spacing around symbols. The one exception to this rule would be Decision symbols, which require extra space to accommodate branch labels.
7. Remember to scale
One of the most basic facts that are overlooked is scaling. Too often a detailed flowchart is re-sized to fit just one page. This is never a good thing. It is better to have a flowchart span multiple pages than to be crammed into a small space, where all the details are unreadable. If you really aren’t happy to span your flowchart over several pages you might like to create a high level flowchart which incorporates several process steps in to one. Alternatively you can also group processes together and then collapse them to reduce the visual clutter of your flowchart.
8. Extended flowcharts
If your flowchart is connected to another flowchart, then instead of putting it in just one page, it is best that you connect it via a circular node to the flowchart on a different page.
Well that’s the first 8 done and tidied away. Keep this list handy and next time run through it at the end of your next flowcharting exercise. We’ll go through the remaining 7 mistakes in the next post. In the meantime if you have a common mistake you think others should avoid let us know in the comments and we’ll make sure it’s covered.