For custom points, you can manually set the directions via a contextual menu thus giving you full control – a point can have multiple preferred directions, all of equal priority. How are those determined? You don't have to do anything for built-in points as those work out of the box – for example, rect attachment points prefer perpendicular directions to their respective sides. You might have noticed that lines' automatic behaviour depends on the endpoints' preferred directions. Manual (orthogonal): mode designed for full manual control of both the midpoints and the segment directions.The user has full control over the midpoints (how many and where) but the segment directions are inferred from the positions of the midpoints. Automatic (orthogonal): mode designed for automatic segment directions but with manual midpoint control.Everything is inferred and the line will add invisible midpoints as necessary to satisfy the preferred directions of the endpoints. Diagram (orthogonal): mode designed to automatically connect endpoints.To resolve all of these problems, I removed the starting direction and introduced four different modes which fully determine a line's behaviour: We can infer the starting direction from the line points and any preferred directions from the line's attachments. Leaving the user to decide the starting orthogonal direction is unnecessary in the majority of the cases.This adds a large amount of friction for every single connecting line – clearly, the app should be doing this for you, not the other way around. If you wanted to connect two sides of a rectangle, you needed to manually add a midpoint so that the line directions on both ends are perpendicular to the rect sides.There were two major problems with this approach: The line itself had a starting orthogonal direction (whether it will firstly go along the X or Y axis). We used to have two types, orthogonal and step. And for the rare times when the app cannot guess your intentions, full manual control is avaiable – the best of both worlds.īefore I describe the changes, we need to revisit how lines worked up until now. I completely changed the way they work, so you automatically get the right behaviour in almost every case. When using ASCII art to draw diagrams, lines are used to connect the various shapes. One of Monodraw's main goals is to make common operations very easy thus saving you time. Depending on how we progress over the next few months, we are hoping to ship the beta in the first quarter of 2015. Once 2015 rolls around, we will be at the final 10% but as it usually happens, those last few bits of work might take a disproportionate amount of time. Once we have shipped the alpha, there is one major feature left for the beta – a special tool that we have kept secret, which we will reveal when the beta launches. At the moment, it seems that I have about two weeks worth of work left until the app is in a state to be distributed to the lab participants – my personal aim is for this to happen before the end of the year. We have just announced our lab programme, so if you want to be one of the first people to get your hands on Monodraw, sign up. As we slowly but steadily complete more of the tasks left for the launch, we are getting a slightly better idea about the time frames. Our stance on the topic has always been – it's done when it's done. I know a lot of people just want to find out when the public beta will ship. Let's take a detailed look at what has been happening over the past few weeks. I have been busy implementing some very important changes that have significantly increased the app's utility and usability. It is time for our second Monodraw beta progress update.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |