DEV Community: ickas

Hack the Hackathon (Part III)

ickas — Tue, 11 Aug 2020 09:42:08 +0000

All the good things come to an end and our mini-series is a proof of that.

So, right now you already choose if you are participating in an online or offline hackathon, and how to gather your A-team. Now it’s time to show the judges who’s the best.

Almost all hackathons end with an evaluation of the projects presented, and it is probably the moment when the participants feel less comfortable.

A lot of energy was spent on developing a project, thousands of lines of code were written, creativity is exhausted throughout the process. But even after that, you still have to prepare a pitch for the project.

Anyone participating in a hackathon has the right to feel like a superhero. It is not easy to build something that is normally developed in weeks or months and with a probably larger team. It is not easy to be creative when the body asks us to rest. It is not easy to prepare a pitch for a jury in different areas and with diverse backgrounds. All of this is only available to superheroes!

We usually leave the preparation of the pitch until the end, even towards the end, when there is no time to prepare it. It is normal, we are focused on developing the project, and we want everything to work, nothing to fail, and this takes time. It takes all the short time we have.

The reality is that we must safeguard this and take the time to prepare the pitch. A good pitch is not easy to do when we have time, much less when we are against the clock and exhausted. You need to know who the jurors are, what their backgrounds are, to find the best way to get the message across and make it understood clearly and objectively. Does the jury want to know how I got to the solution? What technologies did I use? Or does the jury prefer to understand how the solution solves a problem and why? It is necessary to refine this message and sometimes balance it so that in a way everyone will appreciate it.

And as with everything in life, injustices happen. Incredible teams, create incredible projects. But when it comes to deciding who the winners are, not everyone can stay at the top of the ranking.

There will always be those who think that the winners should not be the real winners. In fact, this happens very regularly, and sometimes it becomes quite obscure how the best projects of a challenge were determined. Yes, this happens ... and it sucks!

But, we at TAIKAI have a solution for that! At TAIKAI, we are proud to have a voting system equivalent to investments. We use KAI's (TAIKAI's virtual coin) to back the best projects for each one of us. And each of these transactions is recorded on the blockchain, making the entire process transparent and auditable.

In the end, it is important to keep in mind that the most significant value that can be taken out of a hackathon is knowledge, for better or for worse. What comes beyond that is an extra.

Win-win situation

To conclude, in a hackathon you learn a lot. We evolve as people and as professionals. We manage to enrich our portfolio. We are able to network with an endless number of people. At best, we can win some prizes.

But at TAIKAI, it's not just the Top 3 or Top 5 that end up winning. In fact, the voting system is designed for when we invest in projects. If they end up in the top places, that investment translates into dividends, not only for the promoters of that project but also for those who are investing in them. It is equivalent to an investment in a startup when the investment I madereverts in dividends if it turns out to be successful.

Participating in a hackathon is a unique experience. There are not one hackathon that is the same as the other. The difficulties you have in one hackathon won’t be the same in the next. You end up always having something to learn. Don't forget, failing is still be part of the process, but the knowledge you gain is crucial for your progress.

You can regularly find new challenges at TAIKAI. Stay tuned!

Follow TAIKAI

Website | Twitter | Facebook | Instagram | LinkedIn

Hack the Hackathon (Part II)

ickas — Wed, 05 Aug 2020 14:03:37 +0000

Guess who’s back… Yes, you are right. I'm back to share with you some tips to take the most of every hackathon. Now that we convinced you to join us in the force, now let me share you how to build your dream team and create a winning (or close to it) project.

Dream Team

The team is the crucial point of a hackathon. It is normal to have the group formed, or partially formed before the challenge, but there may be cases where one or more elements are missing. Or even you have the idea for the project, but you don’t have the team to develop it. The important thing is to form an excellent team. When I say excellent, it is not having the best data scientist in the world, or the best frontend developer. To have an excellent team, you just need to find different people and profiles that covers all the areas you need to create the best project possible in the time you have. Do you need a backend developer to develop an API? Do you need a UI Designer to have a presentable project and still give you an excellent logo as a bonus? Do you need a data scientist to analyze a series of data you found online? Do you need someone from the health field because the project requires you to understand specific needs with specific terms? Gotta Catch 'em All!

It is essential to have a team that can respond to the needs of the initial idea. Even if you are alone, you should not be afraid to look for the elements that you think can help you realize a particular idea.

At TAIKAI, we developed a feature that we called "Matchmaking", where both participants and teams can find what they are looking for. On the one hand, we have participants who can be made "available" to join a project. On the other hand, we have teams that can see the available participants but can also create positions that can be filled with particular skills. You can read more about "Tinder for Hackathons" in this article that Mário, CEO of TAIKAI, wrote.

The team will always be the key to success in the challenge. And that success will only be achieved if the team is aligned on the same page. Whether or not you know the team members, communication must always be present. What project to do, how to do it, where and how each one will contribute are examples of how conversation can dictate the success of a project.

Get to work

Most of the time, we have already know the themes of a challenge before the event, and this can be crucial, it is essential to take some ideas of what can be developed.

This brainstorming is essential because you need to understand what you are going to do and how you are going to do it. But more important is to know if it is possible to do it in the time that you are given.

It is quite common for a team to dive into a fantastic idea and start its development without even thinking about what they might encounter along the way. Later, they realize that after all, they will not be able to create what was planned, and that is not because the team is not capable, it is because they do not have time. Time is the biggest enemy in a hackathon. Time does not stop, and when the project comes to an end, it must be presented.

It is essential not to waste time on trivial things - we all know that even the most experience team can do it. How good can it be having the most beautiful logo in the history of logos? There is nothing more beautiful than a project developed in a few hours, and that manages to have an appealing look and feel. Still, there is no need to waste hours on end creating a logo. What is the point of having a project with a login system? Any developer with more or less experience ends up developing a login system, it's something that exists in all online services. What is it worth to waste hours collecting data to training an algorithm when we can probably find a dataset on the internet?

The important thing is to understand what the project needs, what are the really essential things and what can be discarded. Sometimes we are so closed in solving the problem that a right solution is to share the project with people outside the team. It is here that mentors can play a crucial role in giving their view of the problem and whether or not the project is on the right track.

All of this can even seem complicated and a little scary because time doesn't stop. But the truth is that it is the right time to develop something new in an area that is unknown to us, in which we have never worked, using a programming language that we have never used. The short time forced us to have a much higher learning pace, and this in itself already becomes a challenge that we certainly can take advantage of in the future.

But in fact, it is not easy to find the winning idea. There is no magic recipe that tells us which winning project to develop. The important thing is to understand the purpose of the challenge, what it intends to achieve, understand the problem you want to solve and what deliverables are expected.

The truth is that it is ok to develop an idea of an existing product. If it is better, go for it! The world is full of problems, but it is also full of solutions, right?

There's an app for that!

So, it is best not to reinvent the wheel. If we need to use an existing framework, no problem. If we need to develop (but better) something that already exists but in fact does not solve a problem entirely, no problem at all.

And about the code, there's no need to write the perfect code or the most beautiful code you've ever written. Let's be honest, when we are in hackathon mode, we do not accept pull requests, and there is no code review. We just believe that everything will go well and hope that all the things work... sometimes even without knowing how! Unless the hackathon has a "JavaScript Coding Competition", as is the case of Shift APPens, where in addition to the main challenges, projects developed with JavaScript are analyzed regarding its approach and structure.

But things don't always go well. There are many situations where "team" and "teamwork" can be critical. For example, when one of the elements no longer believes in the project, the rest of the team must understand why, what demotivated that person, what they can do to make him overcome it and get back on track. Or when the team realizes that the result that was initially expected is not the one being achieved. It is necessary to anticipate problems or at least perceive them on time so that if it is necessary to stop everything and start over again with a completely different idea. It was one of those situations that happened in the Salazar project and that I cover a little bit of the story in the article "First hackathon, first winner project".

Next week, we’ll talk about project evaluation and how hackathons can be a win-win situation.

Follow TAIKAI

Website | Twitter | Facebook | Instagram | LinkedIn

CTT is challenging you: mailing a letter will never be the same!

ickas — Mon, 06 Jul 2020 19:00:32 +0000

Every time you go to the post office to send a letter or a package, your envelope or box receives a code that contains all the information about it — the equipment, the priority, and others. Can you imagine managing all that data on the millions of packages and letters that are sent every day? Plus using that data to meet the expectations of consumers and companies that are waiting to receive their mail on a specific date? Doesn’t seem like an easy task for the post office services, so any help you can give to take them to the next level will be very well received.

This is what brings us here today. Imagine there was an app able to read these codes and give the logistics workforce all the information they may need, anytime, anywhere, and without complex systems. That’s right. Postal workers could simply download a mobile app and check the information about the mail using their phones. Wouldn’t that make a difference in their daily lives? No more need to access a computer, with an old-fashioned system to check information about a package. It seems that it could be very useful for the optimization of their distribution processes, don’t you agree?

Now that you know what is at stake, here’s your mission: to create that app. But don’t be scared, we will give you access to all the information you may need and you canbring your mates, or come alone and meet new tech enthusiasts, and form a team of up to fivemembers. And of course, we will be available to clear any question you might have.

Did we get your attention? Then let’s see how you should proceed to be part of this challenge led by CTT — the Portuguese company which operates as both the national postal service of Portugal and a commercial group with subsidiaries operating in banking, e-commerce, and other postal services.

How to apply?

Visit the challenge page and register your participation by clicking on the button “Be an Innovator”;
After you confirm your interest, on the challenge page you will have a button to “Create a project” Click in there and then add your name, description and who will join you on this adventure;
Then you can add a lot more content and improve your profile to showcase how good your project is;
Don’t forget to click on “Publish” once you are done to have your project be visible to the jury and organization, and you can edit endlessly until the submission deadline.

But hurry up! You only have until July 31st to register for the challenge and apply for the opportunity to win 8.000€ and you see your solution being used by the national postal service. How exciting is that?

Check the rules and timeline of the competition here.

Follow TAIKAI

Website | Twitter | Facebook | Instagram | LinkedIn

Hack the Hackathon (Part I)

ickas — Thu, 02 Jul 2020 17:35:02 +0000

Hack the Hackathon is a mini-series (it's only three actually) of how you should plan your participation in your next hackathon. I'm here (you already met me from other publications to teach you everything you need to know. Ready?

First things first, what is a hack·a·thon?

We can have several interpretations of what a hackathon is, we can even confuse a hackathon with an ideathon, or with a datathon, or with any other word ending in “thon”. We may all have a different definition of what a hackathon is, from what we hear, from an experience we had, or just because we think it is another thing.

The short answer from Wikipedia:

A hackathon is a design sprint-like event; often, in which computer programmers and others involved in software development, including graphic designers, interface designers, project managers, domain experts, and others collaborate intensively on software projects.

And to make these events even more complicated, we can have a single challenge for several types of marathons. For example, we can have a challenge that starts as an ideathon. But at a later stage, after selecting some projects, it becomes a hackathon to develop and put into practice the ideas generated in the initial phase. No rule book dictates what is right or wrong in this type of event. It is up to each organizer to understand what is best for them and what they hope to achieve in the end.

And after having participated in more than 10 hackathons in recent years, for me, the main goal of a hackathon is to develop a functional prototype of software or hardware. That’s what I’m going to write about.

Online vs Offline: you choose

There are many types of hackathons. We have 24-hours hackathons, we have 48-hours, or we can even have hackathons that run for months. We can have hackathons that have no specific theme and that are open to any type of solution. We have others in which participants will have to develop a solution within a set of topics from a single or more partner, as is the example of Pixels Camp. We can also have a particular hackathon, which aims to find a solution to a single problem, such as the d|Code Challenge.

I love hackathons, whether online or offline. These are challenges that end up testing us, that force us to leave the comfort zone and where we end up learning in a short time what we would probably learn during a month.

Regardless of the type of hackathon, it ends up bringing together a set of incredible people with different backgrounds, but who end up sharing the same taste for developing new products and finding solutions around a problem. This turns out to be one of the best things a hackathon can offer. The community, the networking and the environment that allows us to learn from each other. But also a unique opportunity to meet many other people from completely different areas.

Although the purpose of a hackathon is the same in an online and offline version, they have as much in common as they do differently.

An offline hackathon is more tiring, time tends to pass faster, and it is usually carried out in large and cold spaces. Food is also not the best, but I have noticed a difference in the last few years, where you can see a more careful, more balanced and diversified diet.

In an offline hackathon, the adrenaline is higher, and we get more nervous as time passes. Also, in the final pitch, there are hundreds of people waiting to hear what we have to say.

But the best thing that an offline hackathon can offer is undoubtedly the ease of networking with the rest of the community. We have the possibility of meeting all kinds of people, like CEOs of large companies or developers from startups that build products that we use daily.

In an online hackathon, we also have the networking part. However, it happens differently and probably does not flow in the same way as in a face-to-face event. But one of the significant advantages of an online event is that it can be global and can have participants from all corners of the globe. This makes it possible to have participants from different origins and different cultures, will bring a higher number of solutions presented, and with varying types of approach. The costs of an online event are substantially less than an offline event, and this applies to both sides, those who organize and those who participate.

While organizing an online hackathon does not involve costs of the venue, food, etc., participants also do not have the costs of travel, sometimes overnight stays, etc. But the great thing that an online hackathon can have is a possibility that allows us to be working on a solution for Coca-Cola today and tomorrow for NASA. It’s a game-changer!

In short, online and offline hackathons have several things in common:

Learning: you learn a lot, whether it is a new programming language, a framework, an area opposite to the one you deal daily, or even to communicate better in a team or in public;
Networking: ideal environment to meet new people, to review those with whom we meet in this type of events, to talk to people in front of large companies or ahead of products we use in our daily basis;
Portfolio: in the end, you end up bringing a project to the table, made from scratch by you and your team and in which you must be proud because you gave everything to achieve it in a short period (Hey, here you have a project that we developed in just 48-hours, imagine if we’ve had 3 months!);
Teamwork: teamwork is a vital tool for hackathons and basically for everything in life. Learning to communicate what you can and cannot do in a project, what you want to achieve and what learnings you wish to have throughout the challenge.

Are you feeling the adrenaline to participate in our next challenge? Beware, we’re launching today the d|Code Challenge by CTT. Excited yet? Learn more about it here.

Next week, we’ll talk about how important it is to create the right team and how you can do it easily through TAIKAI’s platform.

Follow TAIKAI

Website | Twitter | Facebook | Instagram | LinkedIn

First hackathon, first winner project

ickas — Mon, 22 Jun 2020 12:56:14 +0000

Let's go back until March 2019, the month TAIKAI endured its first challenge.

After 4 months of development, the TAIKAI platform, like any other SaaS (Software as a Service) platform, had its moment of appearance to the public. But let those who think it was a small event, with few participants, who took place in a controlled environment and who mainly had participants known from the team circle, so that if something went wrong it would not become a catastrophic launch, be disillusioned.

TAIKAI debuted nothing more and nothing less in what is the most significant technological event that happens in Portugal, Pixels Camp.

Pixels Camp is an annual event where about 1600 participants, over three days, can attend talks, workshops, various competitions and participate in its 48-hour hackathon.

The hackathon had 1355 participants. 1355 people using for the first time the TAIKAI platform, which had never before supported an event. 1355 geeks who played the primary role of participating, but still had the secondary purpose of beta testing the TAIKAI platform.

There was even a "Found a Bug in TAIKAI" badge, which encouraged participants to discover any flaws in the platform. And some were found. It only allowed TAIKAI to mature and evolve the platform in such a short time.

Supporting an event of this magnitude, with four months of development, is a risky step, but one that demonstrates the quality of the team that has worked on it until then. In the end, everything that could go wrong went well. The group, in which I was not yet included, that worked hard to make this happen was to be congratulated.

At the TAIKAI debut, I was not really part of the team, but I was at the event as a participant, as had happened in previous years. I am one of those people who love this type of event. Not only for networking and seeing people from the past editions that are convicted technology geeks, but also because I learn a lot. A technology event and especially a hackathon is something that we can and should look at as a well of wisdom and take the opportunity to learn something new. It is something that tests our creativity, our limits working under pressure and gets to have some adrenaline.

As in previous years, Pixels Camp partners launched their own challenges in different areas and themes. In addition to having a free component, where we can develop any project without being connected to any specific partner, there were 15 challenges launched by the different partners.

The base of the team has been practically the same throughout the several editions and this time it was not an exception. Me, Alcides Fonseca, Carlos Mota and Rui Chicória started off for another programming marathon without really knowing what we were going to do and how to do it. We analyzed the available challenges and the choice fell on "Bandersnatch on steroids!", one of NOS' challenges.

Inspired on Bandersnatch movie experience (from Netflix), the goal is to playout video based on user/viewer decisions. However, the path or script can be created dynamically and on the fly (the steroids part).

After seeing how we were going to attack the project, what frameworks we were going to use and what each one was going to do there, we started hitting the first lines of code. Things went well, we were able to identify actors in certain films, what kind of scenes they were, managed to put them together and make them follow a script. But it was precisely there, in the script, that things were not going as we expected. The script built dynamically and randomly was not making sense to us, which led us to have to make a hard decision after 12 hours of development.

We'd already entered the first dawn of the hackathon when we had to decide if we were going to continue with a technically good project, but that didn't produce exciting stories. Or if we gave up on everything that we had done in the last few hours and we would go for something new.

And so it was, the experience that each of us had at hackathons led us to give up everything and think about something new.

At that time, we knew it wasn't going to be easy - 12 hours had passed, hundreds of lines of code had already been written, and we had no idea what project we were going to do from there. We left our laptops and set ourselves around a table drinking coffee and debating on ideas.

After dozens of ideas, we decided to answer one of the challenges proposed by BIT: Autonomous Retail.

Build a completely autonomous customer journey leveraging Continente's APIs from browsing catalogues to checkout enabling interactions with physical touchpoints as product scanning.

We already knew we were getting out of time and will struggle to build it, we knew that we had to be fresh-headed and ready to sit down and get the job done. We decided to go and rest for half a dozen hours and then attack the remaining time of the hackathon with everything we had.

And so it was, early in the morning we started working on the Salazar project (Rubber spatula in Portuguese).

Salazar - Bring that delicious, healthy TV recipe to your table

We have a lot of chefs that inspire millions of people to eat healthy and diversified. They introduce the viewer to new recipes that seem so easy to follow and always result in a magnificent presentation that surely tastes as delicious as it looks. But most of us sit on the sofa for those 15 to 30 minutes, just dreaming of eating that fantastic soufflé and end up having microwaved noodles for dinner.

With Salazar, you have no option but to pay attention to the video. Each ingredient is recognized as you see the recipe and added to your Continente (a large supermarket chain in Portugal) shopping list automatically. The nutritional values of all ingredients are shown, so you can schedule your exercise just before that francesinha you were craving since your last cheat meal!

We have developed a multi-medium application that works on TV, PC, tablet and phone. You can search for any recipe available freely online (Bing video search API), and we'll show it full screen on your display. As the presenter introduces each new ingredient, it is added to your shopping list, and you can still review it before ordering.

As usual, we worked on this until the final minute, even in the time we spent waiting for our turn to enter the stage and present what we developed.

After the final presentations, we followed the voting in real-time. When we saw projects going up and down in the ranking, we started to feel nervous running through our veins. Although there was a selected jury with a more significant number of KAIs, all participants could vote on the projects in the contest. With each transaction that was made at TAIKAI, with each KAI invested in the projects, the ranking changed. Some went up, and some went down. It was a real roller coaster ride until we could really understand which projects were going to stand out at the competition top positions.

It took about 30 minutes for the voting process to be completed, but we quickly realized that we had a chance to stay in the Top 10. Time went by, transactions went on, and we found ourselves discussing the first position with another project. A close vote, now we were first, now we were second, and all KAIs counted to attack the highest position in the ranking.

Salazar won with 137.190 KAIs, while second place was 93 KAIs apart, with a total of 137.097 KAIs. It was probably one of the toughest votes in competitions where either project could win.

TAIKAI passed the first test, the path was long, there were many things to improve, but mainly it was realized that the project had a bright future ahead of it. For a variety of reasons, I immediately identified myself with TAIKAI, mainly because it was something that would bring transparency to this type of competition, which is necessary at the time of voting, making the process completely auditable.

So you can imagine how happy I was when later TAIKAI was looking for a frontend developer to reinforce the team. And that's when I entered the scene. Although I identified myself with the project, I needed to understand if I was aligned with the team vision and what was the future they had for the project. And of course, if the TAIKAI team was aligned with my vision.

In June 2019, I reinforced the TAIKAI team, and today I look back and I see that the path could not have been better. There is still a long run, but what we have achieved in recent months reflects well what we can make in the times ahead.

Follow TAIKAI

Website | Twitter | Facebook | Instagram | LinkedIn

TAIKAI Platform, First Year in Review

ickas — Thu, 12 Mar 2020 18:07:00 +0000

This is an annual retrospective over what we achieved so far in 2019 and what are our plans regarding the TAIKAI product for 2020.

2019 was a rewarding and extremely active year for us. We launched our website, organized some amazing initiatives with Bright Pixel, Instituto Politécnico de Tomar, Sonae MC, EDP, Glintt, CeSIUM, Web Summit, NOS, LTPlabs, Porto Business School, JUNITEC and Nova School of Business and Economics and started the first steps to achieve our long term vision.

All the initiatives that we were involved, proved that our “Future of Work” vision makes sense and served as a playground to optimize the gamified token-based system that we want to put in place to manage online/offline challenges and to reward the stakeholders that create value on our online community.

This blogpost serves as our year resume and provides a little bit of insight into all the major product feats and updates that marked our journey in 2019.

MVP (Minimum Viable Product) — First Version

Since we started the TAIKAI product development, we had in our mind our first key milestone: deliver a minimum set of features required to support the Pixels Camp hackathon.

Pixels Camp is a yearly technology event, organized by Bright Pixel where the biggest Portuguese coding competition takes place with more than 1300 participants sweating to deliver the next big idea and win amazing prizes.

The first version of our platform and our landing page was launched one week before the event and allowed the participants to gather in teams, submit the coding challenge solutions as a project, provide the presentation for the final pitch as long as other project resources.

After the pitch presentation, all the hackathon participants and event partners used the platform to select the best projects and follow the real-time results on the event screens.

The platform worked almost flawlessly and our infra-structure sustained the traffic load during the stressful 30 min voting period that was defined to select the best hackathon product.

In summary, on our first real test, running on our private based blockchain network processed more than 10000 transactions and allowed us to identify some improvements required to enhance the user experience and the required challenge management procedures to operate an event of this nature.

EOS Jungle Testnet Migration

The smart contract that was responsible for managing all the on-chain transactions and KAI token wallets was migrated to the public EOS Jungle Testnet from the private network delivered on our MVP version. This migration allowed us to battle-test our smart contract on a public network and to prepare our infrastructure for the final migration to the EOS main net.

During this migration, we measured and decreased the CPU time consumed by our transactions and we optimized the EOS RAM required to run our platform on a public network.

Challenge Multistep Support

After some iterations with our clients, we came to the conclusion that our challenge strict timeline was not compatible with the challenge promoter needs. The 3 phased challenge, IDEATION-VOTING-END, didn’t support multiple voting phases and was quite difficult to fit in all the hackathon timelines that we were supporting.

To solve this issue we developed a configurable challenge phase timeline capable of accommodating different project permissions, voting schemes, jury sets, and qualifying rounds.

Content Management System (CMS)

Since we started managing challenges for our partners, we identified some common procedures that we were doing with custom scripts on our internal database. The system management with scripts was making our operation life poor, it would put all the effort on the development team and didn’t allow our customers to make content changes in the production environment in a flexible way.

In order to reduce the challenge and production environment operation cost of our infrastructure, we developed an independent web application to manage the challenge’s content, participants, backers and some global day-to-day operations required to sustain our business.

The end goal of this application is to provide a back-office application that allows the challenge promoters to self-manage all the online/offline challenge content, participation and voting steps in a comfortable user interface application.

The first version of this application is only visible to the TAIKAI team, notwithstanding, we are planning an upgrade to enable the event organizers to use it and self manage the event without our team intervention.

Design System

With the growth of TAIKAI and our plans to develop a CMS we realized that it was time to standardize the user interface components used in different projects so that in the future there would be an improvement when designing new interfaces and also improving the development workflow, thus was born our design system.

Our first step in creating an excellent and solid design system was to create something between a style guide and a pattern library with all the elements, colours, icons, fonts, templates, etc. and from there to develop the components and their code snippets.

There are numerous ways to create a design system and how to organize all its components. We opted for the Atomic Design methodology, created by Brad Frost. To manage all the styling, from the three main approaches we could take, Global CSS Files, Modular Stylesheets and CSS-in-JS, we opted for CSS-in-JS with styled-components, a framework which lets us use current CSS syntax inside each component and solves many of the problems with traditional CSS.

Rewards Algorithm v1

One of our end goals is to recognize and reward people that create value on TAIKAI internal economy.

The current TAIKAI stakeholders are the challenge contest solvers and the project curators that select the best project submissions that act like curators on any challenge initiative running on TAIKAI.

Using gamification and token incentives we devised a deterministic algorithm that rewards back KAI tokens to project members that were part of the projects that finished on the first places of our challenge initiatives.

Moreover, the challenge juries are also rewarded based on the challenge final results and based on their wise project investments.

The reward amount received by solvers or juries takes into account the amount of KAI received/invested respectively during the “voting phase” and is distributed after the challenge is finished.

All the reward transactions are forwarded and validated by TAIKAI smart contract for further audit and analysis.

Notification Center

For real-time notification of all the actions and transactions performed by the user, a notification center was created to accommodate a succinct resume of all the user actions, KAI transactions and challenge updates. Apart from the internal notifications, the user could optionally enable the notification settings required to receive a more detailed summary of their actions on their email.

Messaging One to One

We know that a key point in a social platform like TAIKAI is the direct communication that will exist between the promoters of a challenge and the innovators, or even between innovators.

Whether it is for questions about a project or future collaboration, this communication can happen on several occasions and for various reasons. We took the first step to facilitate communication between all TAIKAI users and launched the one to one messaging feature for all registered users.

Work & Academic Experience

To make the profile of all users more complete, so that it not only encompasses their project history, challenges and transactions but also all their experience in their professional career, we have some features in the development pipeline. We started by adding two new sections where all innovators can manage their academic and work experience.

Next Steps

In the next couple of months, we hope to prioritize the features that allow us to improve the TAIKAI platform user experience and sustain the operation growth expected at this stage of our history.

Additionally, we will release product development updates bimonthly and share with you our new product features to get your instant feedback and steer the product in the right direction.

In 2020, we want to successfully migrate our smart contract to the EOS main network, enhance our token economy incentives and social recognition system and launch more recurrent challenge initiatives on new verticals.

Can you help us on this journey? Drop us an email to hello@taikai.network or contact us through our social networks. Your contributions are invaluable to us.

The rocket took off and it’s eager to conquer new worlds! 🚀

Thank you for reading!
Want to learn more about us? About what we do? Check our website or ping us on Twitter

Why developers and designers should work with each other

ickas — Wed, 08 May 2019 14:48:01 +0000

I wrote this article five years ago, but I think he's still applied to the present. So, here he is!

There is a reason for so many group tasks in school. Starting in kindergarten and ending in college, every single person is encouraged and taught to perform in groups — a drawing, a sculpture, a volunteer project, a scientific experiment.

Knowing how to work as a team is an essencial skill for life, both personal and professional. The society moves ahead if it works together, where each one of us has their part. This maxim is valid in every kind of jobs. If I’m a designer just working in web design, someone has to implement my work, and that person would be the so-called developer. It is also possible to be both, designer and developer, but in this article we’re just going to focus on the most common situation nowadays, which concerns to a team with a lot of elements, two of whom are the designer and the developer.

Magga Dora, an experienced designer, said:

Great developers makes me a great designer because they make my design come alive and improve it in the process.

Let’s go by parts to understand who are these two characters.

The human brain is divided in two hemispheres: the left and the right. Although every human being uses both hemispheres, most of us has a dominant side, which affects the way the information is processed, how to react to that information, how to face the problems and how to communicate. Only 2% of the humans is right-brained, the side that is responsible for the creativity, the curiosity, the fantasy, the intuition and the symbolic thinking. The others 98% are left-brained and are associated with the logic thinking, the rationality, the rules and the communication. Since the designer’s work is creative, imaginative, and intuitive, he is normally right-brained. This means that a web designer is the one who uses graphics/pictures to create a look, a shape, a face, an interface to the web or to an app. This design needs to ‘marry’ with the code in order to get alive.

In this marriage, the groom’s parents of the design and the code are the designer and the developer. This last one, unlike the designer, is normally left-brained. He is oriented by the detail, by the specificity and he looks for a clear and functional code, not giving to much importance if the final result is appealing or not. The developer is the one that builds the backbone of a website, through programming language (HTML, CSS, JavaScript, etc.), giving life to the design previously created by the designer.

In a team, the work of all elements has to lead to the common objective, in other words, creating a website or a app that seduce and attract the users. We are talking about the concept of User Experience — UX. Like Ximena Vengoechea said, this is not just a fancy word for common sense. The User Experience is a fusion of knowledge, it’s multiple lines that merge in a common spot — the creation of the best user experience possible, achieving, likewise, business goals. Creating something that people in general like is a really tricky and challenging deal and to do that’s necessary to understand psychology principles about the human behaviour and the formation of the person’s personality. There are a lot of key points in UX, among them:

The visual look of the interface — using the elements to transmit some specific message;
The information’s architecture, which means to group it in a meaningful way according with its importance regarding the context;
To get to know the market opinion trough surveys;
The interaction design — getting pages that are in agreement with the idea that’s supposed to share or with the behaviour one wants the user to have;
The usability — making sure that the system is accessible to everyone.

UX is, therefore, one essential requirement for the success of a website or an app. The best way to cross this finishing line is the team work between the designer and the developer. None is more important than the other, both need to be listened. A website has to be beautiful and flashy, but it also needs to be functional. The sum of the visual look with its functionality should reflect the brand and ought to attract visitors. The web designer can’t just do his job, send it to the developer, and in the end blame him for the unexpected final result. On the other hand, the developer can’t ignore the concerns of the designer regarding the graphic look.

If you’re a designer and you want your partner developer to listen to you try to do this: explain to the developer what you’re doing and why. Some developers don’t have an easy eye to design, but most are concerned about UX. So, you as a designer can tell the developer about why you think your design is the best for that work and why it should be built just the way you did it. And most importantly, when you think that something isn’t right, tell him and explain your ideas instead of complaining about his work.

On the other hand, the designer has to make an effort to understand basic development concepts, like knowing what a MVC framework is and the limitations of JavaScript. They should know what is possible and what is not. Some also say, that a good idea to make a designer get along with a developer is to sit them side to side, in a way that they are “forced” to be nice to each other. That been said, the key is always communication.

So, whether you are a designer or a developer, remember that both parts are important. Work as a team focused brands like Apple, Disney, Google and Coca-cola, real queens in User Experience.

Reset or not Reset CSS?

ickas — Wed, 26 Dec 2018 12:50:19 +0000

In my last 4 or 5 projects I dropped the reset CSS and just add this:

* {
  box-sizing: border-box;
}

body {
  margin: 0;
}

CSS reset is great, sure! Saves a lot of hours of tests... and a lot of headaches. But have you tried removing the reset css from your project and see if it makes a big difference? After using a reset CSS already looked at your project with an accessibility perspective?