Would you drop your mouse for your eyes?

How long did it take you to click on this blog? You had to scroll your way with your mouse until you reached the clickable text, right? Or you clicked at it with your finger directly on the screen… On the other hand, how long did it take you to look at this blog’s title? Milliseconds. Yeah. That’s what I mean.

It’s now been over a decade that we’ve been using the computer mouse as a fundamental tool in our interaction with computers. It’s not the only way we point at things, though. Mobile phones, mainly thanks to the explosion the iPhone brought, have also taught us we can directly touch with our fingers on the screen. Augmented reality has also taught us to use the movement of our body, with cameras and motion detectors.

But, think about it. All these interactions I’ve mentioned need another type of interaction none of them are truly taking into account. Before you ever move your mouse, touch your screen or move your hand in the air, the first thing you do is point your eyes at that thing. What if we took approach of this very first thing everybody does? Eye-tracking technology. That’s what many predict the future holds for us all. A multimodal computer interaction.

What most of us have now in our pockets would have been considered a supercomputer 15 years ago. And the revolution’s not stopping anytime soon. “The general notion of pointing at things to navigate through a menu can be done in tens of milliseconds with you eyes versus the time it takes you to use your hands”, says Jim Magraff, CEO of Eyefluence, a company that now builds eye-tracking technology for AR and VR.

Communication with computers should be seamless, no delays nor interruptions. An “iPhone moment” could happen anytime soon with eye-tracking technology, with the potential propagation of multimodal human computer interaction. What do you think? Imagine how big a leap this would be for disabled people.

I can personally think of some very cool analytics you could do… Imagine if you could know which parts of your webpage people look at immediately, which hold their attention the longest, if they read through your blogs from beginning to end (though for you to be reading this far, you hopefully did! 😄). But, I can also think of some very obscure ways this could be used… Or even some annoying ones like an ad pausing yourself if you look away from it. You couldn’t help it but LOOK through the entire thing...

Have a look at this. I dare you not to use your mouse:

If you want to take your reading any further, this is the source I used:

https://techcrunch.com/2016/09/14/the-future-of-human-computer-interaction-will-be-multimodal/

Nonfunctional is worthy, too.

Okay, so you’ve most certainly heard about requirements before. At least you’ve read about it on my blog (please? 😢). And probably you don’t have the full mental image of actual requirements, because most requirements definitions only focus on functional requirements, actually.

These so called functional requirements are based on the expected functioning of the product/service. This is typically represented in features such as menus or buttons. Here is where you want to think about potential use scenarios. For most cases, though, if you fail to identify some nonfunctional requirements, you’ll have some trouble later. Trust me.

A milk container has the functional requirement of being capable to contain fluid without leaking. Of course, milk containers can also be used for other things:

Now, nonfunctional requirements are those regarding attributes such as performance levels, security, usability, reliability and availability. Here is where you you want to think about user narrative statements, acceptance criteria. When these factors are not taken into account, not even your perfectly well functional requirements will save you from some very unsatisfied resulting customers. This highly increases the chances of abandonment.

A hard hat has the non-functional requirement of not breaking under pressure of less than 10,000 PSI. Now, let me just say there are some pretty cool things you can do with hard hats:

And I don’t blame you, the fact that they’re called NONFUNCTIONAL requirements already makes you think it’s not worth of your time, as if nonfunctional meant pointless, secondary, negligible. I hope you’ve learned here otherwise. It might help to make a mental image of them more as “quality requirements”. That rings more the bell for most of us.

Functionality and quality don’t cancel each other out, in fact, they live as one in all successful software. Both functional and nonfunctional requirements are actually considered part of high-level design, as the two serve the purpose of product specification. Now you know the difference between functional and nonfunctional requirements, as well as some awesome things you can do with milk containers and hard hats ;)

If you want to take your reading any further, these were my sources: http://searchsoftwarequality.techtarget.com/answer/Functional-requirements-and-nonfunctional-requirements-in-software-engineering-explained

Time to talk about APIs

This means Application Programming Interface, by the way. That may not help much, though. Even so, most surely you’re already using them every single day… Let me just mention you a few ways APIs involved in your daily activities: Facebook, Yahoo, Youtube, Amazon, Twitter, Pinterest, Reddit, Foursquare, Instagram, Pandora and even WhatsApp. Don’t tell me you don’t use any of these. There are widgets, buttons and badges everywhere making you pull and push content to other sites.

You might want to think of APIs as a wall socket. These electrical sockets are essentially interfaces to a service. You’re a consumer of this service. You don’t need to have your very own power source for you to be able to charge your electrical devices.

Now, back to reality, you use APIs as an interface to some other application/website service. You’re a user of this application/site. It’s through this API (make it widget, button, badge or whatever), that you don’t need to use the application/website as a whole, but only a small part for which the API was specifically made for.

There are even more detailed ways of having an API. A few examples: thermostats, smoke detectors, automobiles, clothing, glasses, etc.

And it’s logical. I mean, if you want as many people as possible to use your product/service, why wouldn’t it be a magnificent idea to split your product/service into tiny, functional, very specific parts (APIs) that can be implemented through other applications/websites or whatever; your users won’t have to be moving from one place to another to do as they desire. And that’s very, VERY important :)

Here I leave a video showing IFTTT (one of many API enabled orchestration platforms), a service that takes approach of many, many APIs out there and lets you combine them in practically infinite ways to do pretty much anything you want. Specifically, a video showing what 2 guys can accomplish in just one day of playing around with APIs. Enjoy!

Thanks for reading my blog, you're an awesome person.

If you want to read further, these were my sources:

http://www.programmableweb.com/news/what-is-an-api/analysis/2015/12/03#apiu#What Are APIs and How Do They Work?

http://101.apievangelist.com/

SLDC... What?

SLDC. No, it doesn’t stand for some sexually transmitted disease. At least not in this post.
Software Development Life Cycle, that is. Okay, but what does it mean?  Essentially, it’s the thing you should do to ensure some software gets to be and stays good.

                         

For this to happen, you first observe; you’ll be making some investigation and analysis. This is very important, it will tell you where to go, what you’ll need; you define expectations and requirements, communicating with the end users. You can do this by doing interviews and surveys, considering multiple cases that describe what users might do (or even show real-life users some prototypes).

Only after you gather this detailed information, should you start planning: you establish technical requirements (hardware and software) and security processes/vulnerabilities. Further specifications like how the user interaction will be (entry fields, buttons, screens). You should also think about how easy it would be in the future to add new features, and make modifications.

Then, what would maybe be your first step had you not read this: coding. The difference is that by this point you have expectations at which to aim, user-desired features, hardware/software limitations, parameters to be tested and tweaked. After this phase is completed, you’ll have the finished product, but not the end of your hard work; after every coding milestone is reached, you have to evaluate how close it came to what was actually planned. However, you should also be open-minded for unexpected changes and issues. Team communication is crucial here, for progress to be really accomplished and not get stucked on some sort of loop.

So what do you do next? Well, you can’t (shouldn’t) just launch your software like that, testing should come first. You’re going to want to consider how your software will be implemented in different environments, as well as its user acceptance. Be sure to document every step of your way, so anything can be referenced in the future. Bug capturing tools might save your life at this point. This might lead you straight back to the coding phase, or even the design phase!

Ok, so we’re done with testing. Finally we can start the deployment/implementation! Depending on how your user-testing went, you might want to decide to train end users, or at least have some initial guiding for how to use your product (although not always necessary). You’re going to want to consider location factors.

If you’ve made it this far, don’t expect it to be the end. For software to be reliable and updated, you should frequently reevaluate its whole concept from the beginning multiple times. You know, that’s why it’s called a cycle. If it weren’t, why not just create a product that’s only usable for a short time, under certain conditions and with no real future implementation? You don’t want to do that. Please.

A Glimpse at Software Engineering History

Software Engineering. I’ve talked about it, you’ve heard about it, but who was first? How was it originated? Here I’ll try to summarize the story behind it, and some milestones that shaped the world we now know.

You might instantly try to to be thinking about which programming language people used back then, but no. Programmers back in the 50’s-60’s delivered programs by HAND, so that only hours later all the mechanical-electrical processes could be finished. This was very difficult to rely on, and led to high costs in the industry. This so called “software crisis” made it pretty clear some better solutions had to be found. Traditional engineering practices were sought to be applied to software, and over the next few decades some key ideas emerged that allowed engineers to break down projects into tinier (modular) pieces, communicating via interfaces.

One of these key ideas happened in early 1980’s, when thinking of data as objects that held independent states and could interact with each other began to emerge, the so called “object-oriented programming”. This lead to easier creation of GUI’s with menus and windows and improvements in security. At the same time, computing power increased at an incredible pace. As good as this was, it also made it possible for code not to as efficient as before, with much more memory and resources available.

Then, let me take you straight to 1989 when the magnificent Web emerges with the help of Tim Berners-Lee in Switzerland with one of his papers. However, it wasn’t until 1990 that a little of what you might imagine as “web” came into place, with users being able to have a graphical access to pages.

Then (oh, yes!), we also have the open-source movement in the 90’s which removed corporate code barriers, allowing an explosive expansion in software. This means not only the executable binary code was released, but the actual code whose compilation led to the binary executable. Consider this, together with how the cloud began to allow applications to be accessed in real time and the rise of the mobile industry (tablets and smartphones), and you have a little glimpse of how software engineering has come to be what it is today. If you ask me, today is just easier than ever before to develop your own next revolutionary idea, with so many tools at our disposal, and the ever-increasing pace at which software is being released to us.

Software Engineering. What?

Software Engineering. Perhaps you’ve heard it before. In fact, for you to be reading this, you most certainly have.

The Association for Computing Machinery (one big joint amongst others in the software world) defines it as “developing and maintaining software systems that behave reliably and efficiently(...)”.

Now, you could say that sounds very similar to what you think of computer science. Yes… but no. They’re 2 different majors. Typically, both have within their curricula programming fundamentals and basic computer science theory. However, computer science tends have few core topics, so that students can later choose where to go next (networking, artificial intelligence, database, etc.), whereas software engineering tends to focus on a broad range of topics essential to building solutions that are useful and usable.

In this way, one might come to understand these two as the “artist” and the “engineer”. Computer science could typically be more involved in developing the theories and research that later become tangible things after the engineers set it up. But, it could also be the other way around. For as much as you have a major in one or the other, in the end it all comes to the way you approach things.

You shouldn’t categorize majors as either crafts or engineerings. If you’re up for categorizing things, then look at each person with these majors. None of them are exactly the same, nor do they think the same. They have different grounds and knowledge, yes, but might think as artists or engineers, or who knows what else...