KATERINA: Hello! That’s a lot of people and I’m nervous. So if I’m looking at you, just nod along so
I feel more confident. The actual title of my talk is from buildings
to software, paving the way to construction. So a few words about myself. I’m an architectural engineer by training,
and currently I work as a frontend developer at Upstream, which is the leading mobile commerce
company in Greece. And before that, I used to work as a web developer
at the national center for scientific research, Demokritos, in Greece, where I had my first
encounter with Angular and professional web development. Which was the summer of 2015. So obviously it was Angular 1. So how did that come about? I was given a project to work on. Sort of a website. And I was the only dedicated frontend developer
for that website, and I had to choose my tools. It had to have a live feed, it had to have
user comments. So I chose Angular. Why did I choose Angular? Because a colleague had mentioned it. It was Google and I knew it had a strong community. And I tried the tutorial on the AngularJS
website. And I really liked it, because it reminded
me of a lot of principles that we were taught in architecture school. I’m going to explain how. So I live in Athens, Greece, with my cat. So yeah. So basically today this is going to be a not
so technical talk. I’m going to ease you into the conference
with the not so technical talk. Basically I’m going to make an analogy on
how building a building is similar to building software. So first we’re going to have a crash course
in architecture and how you’re laying out a building. And then we’re going to talk about how you
can lay out your web application step by step in a similar way. Then we’re going to do a recap and I’m going
to talk to you about the reasons why I think this is helpful. So my initial thought for a title was building
software — it was sort of a play on words. You have two nouns where people think it’s
a verb and a noun. Some buildings and some software. To make the analogy. But basically the talk is: How designing buildings
helped me design and, well, build software. Steady software with a robust base. With a well defined structure. And a variety of structural elements. I believe you see where I’m getting at. So yeah, when you’re in architecture school,
you are given a task every year. So, for example, say that the task is to make
a community center. So the community center has some parameters. Such parameters are that community center
has to have specific activities, for example. Have a theater, library, a cafe, it should
be no more than 500 square meters, because this is the area you have available. It should follow some local municipality guidelines. So accessibility, appearance, branding. And you have to think of the end users, which
are the residents of the quiet family neighborhood, for example. So you have your problem, your task. And you have your parameters. You do your research, you analyze your parameters,
you see the legislations, the guidelines, and you grab your pen and paper and you start
drawing. So first of all, you do the sketches. Some initial sketches would be about how you
want your users, your people, to navigate through the building. User flow, where to go. You start drawing some shapes. You start drawing and adding shapes and lines,
until your building has sort of a final form. Once you know how your form is going to be,
you can start making some plans. First you plan on a large scale, so you know
where the space goes, how much space each individual room takes, so you have your larger
scale plan, and then you can move on finer scales, and start adding structural elements. The components like you see here — we have
tiles. We have furniture, stairs. So then you can go into more detailed blue
prints, where you add elements and components in the whole building. You can add chairs, you can see how a wall
is built, with insulation, bricks, and concrete. And you can go into so fine a scale that you
can design the shades or the glazing. So how is that similar to designing a web
application? It’s step by step. You recognize the needs of your user. You set down the plans. You start scaffolding. You define your components, your structural
elements, and you create some screens, and you start coding. I’m going to make a analogy here. This is a joke. I’m just making this clear. So say that you have a house. And if this house were a web page — it’s
a joke, again — it would have a roots tag, which would be the building, it would have
some beams as components, it would have columns, other components, it would have a wall, and
inside the wall, it would have insulation and brick, a stack of bricks. Okay. I’m glad you’re laughing. Because I was thinking of adding canned laugh,
at some times like this, when nobody laughs. You have your roof, the attic window, the
door has a frame, glazing, handle, apron. So you can see that everything has more components
and more elements inside. And you have the chimney. It’s a joke, again. So let’s see how the process of laying out
step by step a web application would be. So say, for example, that I want to make a
web application that is my digital portfolio. What would be the requirements? I would want it to have a list of my projects. I would want to be able to add a new project,
to edit an existing project, like the embarrassing ones from my first year in college. It should have users, like my future employers. And it should be available on the web and
the mobile web. This is my problem again. These are the parameters. So what do I do? I start drawing. So first, again, you want to see… Sorry. You want to see how your users are going to
navigate through your app. So you create a navigation tree. You have the root of your application and
you would have some separate screens. For this application, I would want to have
a home screen, an about screen, and a contact screen on the same level. And then, for example, I would have the project
details. Then I would have the bearing structure. Which would have some components that would
be the same throughout the whole application. Which would be the header, the menu, the content
container, which is going to contain all the pages inside it, and the footer. Then I have the front page. Then I have the header, the footer, the content
container, and then the list of projects. The about page would have header, menu, content
container, footer, text, and a photo. And the contacts page would have header, footer,
content container, a map, and social media buttons. So… So you see that from the initial drafting,
you can initially start seeing how the structure of your application is going to be. We’re just drawing some sketches. So now we can see some mockups. The disclaimer is that it’s not a user interface/user
experience design presentation. So don’t judge. All elements are from the Material Design
sticker sheet. So at this stage, your mockups are your large
scale plans. So you just have some rough mockup screens
you put together. Initially they can just be a laying out of
elements. So we’ll make sure nothing is left out. And it’s large scale. There’s no need for details or any fine tuning. You just need to see that everything will
go wherever you want to go. So you would have your front page. And a new component would be a list item and
a button. The about page would have the header, of course,
and the menu, and would have the text and the photo. The contacts page would have an editable element,
which is going to repeat itself. It would have the map. And you would have social media buttons. The details page, again, it will have a carousel,
edit buttons, which are going to repeat themselves, and the new project page, which we forgot
before, has the button from the front page, the edit button from the previous page, and
the editable elements. So again you see more components come up and
you note them down and you know how and where to put them. So what did we learn from this stage? From the draft mockup screens, they reveal
elements that we never thought were there, or we didn’t think of them before. So that we can plan our code and the procedure
of making our code better. This can keep us prepared and informed about
what to expect. So to make a better plan. And sometimes you really need a UI/UX designer. Just as you wouldn’t go about building a house
without the plans or the architects. Yeah. I have to tell you, I scrolled really far
down to find a woman builder that didn’t look strange. Okay. So at this stage, you move into the finer
detail mock screens, the live demos, the header, which I’m not going to… This is just some general idea. I’m not going to go deeper into details for
this. But it’s similar to the more detailed finer
scale plans. So yeah. After you have this, you start implementing
the plan. So again, this is a screen of AutoCAD. This is a computer-aided design. And the other one is just another analogy
here. So the recap. Again… The way of… The similar way is that you start with doing
a draft of your navigation tree. Then drawing the draft of your screens. Then drawing some large scale mockups, which
don’t have details. Then finer details. Then you start coding. And this is my Twitter screenshot. You have your website. So why is this important? And why am I here today? Why am I sharing this with you? What is it good for? In my previous job, I had a colleague who
had studied architectural engineering. He’s ten years my senior, and he had moved
from architectural engineering to software engineering. Now he’s writing C++ somewhere. And he used to always tell me — he was my
mentor, my personal Yoda — he always used to tell me that the programmer has to grab
a pen and paper and the planner has to write some code. About the second part, I’m not sure why he
told it, but about the first part, what he meant, I think, is that you have to actually
grab your pen and paper. You have to start to lay out your whole plan,
and you have to have a whole image of what you’re going to do, in order to be prepared
and know exactly how to do it and what to expect. And you never really know the full scale,
until you have planned it before. So what is helpful in this approach is that
you planned your work in detail. The planning makes the task easier, because
if you have a big problem and you break it into small parts, it becomes more manageable. Sorry. It helps of course if you have better estimates
for how long anything is going to take. It prevents from unanticipated issues, like
creating a bunch of code that should be broken up or should be together, and your code is
more scalable. It’s easier to maintain. Easier to change. You can more easily add new things. So Angular gives you the tools for that. So why not use them? You have your components. You have your templates. You have your rooters. So they’re there to help you do just that. So if you type into Wikipedia: Software build,
it says in the field of software development, the term “build” is similar to that of any
other field. That is, the construction of something that
has an observable and tangible result. So obviously… Yeah. I began with architectural engineering, studying
it. And I found transition into web development,
because I really never liked architectural engineering, that there were skills that I
had gotten from this, that really do cross over. And some building and design techniques do
help you. So building design is a very old discipline. And the process of designing a building is
very similar to that of designing an application, in the sense that you need drafts, you need
detailed plans, you need structural elements, and a full fine-scaled blueprint. And this process has been tested for thousands
of years. I mean, they had this — the building design
discipline is so old. So why not use these techniques in software
development too? And I know most of you do. But just for those who don’t… Just do it. So these are the components that Angular gives
you. The structural elements. So you wouldn’t build your home without planning
it out first. So why do it with your homepage? So just remember: It’s not necessary to build
software that looks like a building or group of buildings? Who gets this reference? Is there anybody here who gets this — yes. It’s Jurassic Park. The velociraptors are chasing the family and
they’re hidden in the building where all the software thing is going on. And the girl has to run a script that will
lock all the doors and lock the velociraptors out. She goes to the computer science and she goes… Wow, this is UNIX! I know this! Well, it’s not UNIX exactly. And there’s actually a 3D file system navigator
from Silicon Graphics. And she goes there and tries to navigate through
the buildings, that — each of the buildings are the files. And it’s very fun, because it’s very difficult
to navigate through the buildings. So she does. She finds the file at the last moment. Yeah, but this is not a good example. Because she actually almost fails. Yeah. So that was the presentation. Thank you. (applause) And yeah, this is my Twitter handle. So if you want, you can follow me on Twitter. And yeah. That’s it.>>Great. Thank you so much. Okay. We’re running a bit early here, so you’ve
got a bit of a longer break. Up next in the main track, which hasn’t finished
yet, so if I can ask you not to go in there yet, will be responsive layouts with @angular
and Flex-Layout. And in here will be introduction to web application
security. And we have our first panel happening in the
Pluto room, which is i18n and accessibility. Thanks very much!>>Hi, welcome back, again. If you can put up your hands if there’s a
seat next to you that’s free, there are seats here. Feel free to come forward and sit down. Okay. So up next, Dominik is developer for Twilio
in Berlin. He has a passion for teaching and good whiskey. He’s here to give us an introduction to web
application security. Please welcome him to the stage.

From Buildings to Software – Paving the Way to Construction โ€“ Katerina Skroumpelou
Tagged on:                 

Leave a Reply

Your email address will not be published. Required fields are marked *