ZebraHack4.0

What you will develop

The 2026 challenges will be revealed at the event. Follow the challenge announcement for details.

The rules of the competition

1. Teams must have three or four members to participate. You can register with one or two members and complete your team later using your private edit token, while registration is open. Each student can belong to only one team at a time. Captains can use the private edit token to disband their team and free all members to join other teams.
   • Registration is limited to 10 teams per serie. Availability is checked when registering or updating a team.
2. Teams should be made up exclusively of second year “Web technologies” undergraduates who are not organizers, volunteers, judges, sponsors, or in any other privileged position at the event.
3. The intro and the announcement of the winners will happen in person at the Faculty of Automatic Control and Computers, EC Hallway.
4. All team members should be present at the event.
5. Teams can, of course, gain advice and support from organizers, volunteers, sponsors, and others.
6. No development may start before the actual date and time of the event. Any teams that violate this rule will be automatically disqualified.
7. The project must respect the challenge.
8. You should only use standard HTML, CSS, and JavaScript executed in the browser. Teams cannot use application frameworks that require a build step or runtime other than the browser (for example React, Vue, Angular, Svelte, Next.js). You may, however, use client-side libraries loaded directly from a <script src="..."> or <link> tag (for example the mapping, charting, or graph libraries mentioned in the challenge descriptions), as long as they do not require bundlers or transpilers.
9. All code must be written during the hackathon. Using code from previous projects, tutorials, online examples, or open-source projects is not allowed, except for libraries and frameworks that are explicitly permitted.
10. Working on a project before the event and open-sourcing it for the sole purpose of using the code during the event is against the spirit of the rules and is not allowed.
11. Usage of AI tools (like GitHub Copilot, ChatGPT, etc.) is not allowed for generating or directly editing any of the project’s HTML, CSS, or JavaScript code.
12. Participants must have an active GitHub account before the start of the event.
13. All the teams must have at least one commit with their work by Saturday, 14:00.
14. Teams must stop working at 16:30. After working finishes, teams must submit their projects and presentations to GitHub; a repo must have two parts to be eligible for judging:
    • the project’s code;
    • the project’s presentation (PowerPoint, Google Slides). Here is a template you can use.
15. After working finishes, teams will show their projects to each other and to the judges. Each team will be given 5 minutes to present their ideas. You are strongly encouraged to present a demo of what you have built.
16. You are encouraged to present what you have done even if your project is broken, or you weren’t able to finish. It’s okay if you didn’t finish your project—that happens all the time! Demoing is not just about the competition. It’s a chance to share with others what you learned and what you tried to build—that’s what working’s all about! In the case that you don’t have anything to demo, you can give a presentation about what you tried and what you learned. Hearing what other people learned is interesting and inspiring for other attendees.
17. You are expected to come with your own personal gear (laptop, monitor, headphones, extension cord, etc.).
18. All project submissions will be code-reviewed. Applications will be spot-checked by code reviewers and mentors. All the projects selected by the judges as finalists will be code reviewed to confirm that the code is original work created at the hackathon and that all components and assets conform to the licenses allowed in these rules.
19. After the hacking time ends, the jury will take some minutes to deliberate on the winners.
20. All the participants who will present their project will be given participation certificates. Winners will be given merit certificates.

Judging Criteria

Teams will be judged on these four criteria. During judging, participants should try to describe what they did for each criterion in their project.

• Technical Mastery (30%): Is the project technically complex? Does it seem remarkable that someone could achieve this hack in just less than 8 hours? Does it work well? Does it look and feel nice?
• UI / UX (30%): Is the project user-friendly or intuitive? How consistent is the design for the entire application? How impactful is it? How innovative is it? Is it relevant to the chosen theme?
• Pitching (20%): How well did the team present their project? Was the presentation engaging? Did they demonstrate passion and enthusiasm for their project?
• Challenge fulfillment (20%): How well did the team meet the requirements of the challenge they selected?

Technical Mastery

• The HTML document should follow a semantic structure. See web.dev.
• The website file structure should contain:
  • Assets (images, videos)
    • Should be in a separate folder.
    • Their file names need to clearly indicate what they are.
    • Consider if you want some assets to also be organized in folders depending on the page they are used on.
  • Styles (CSS files)
    • In a separate folder.
    • You will likely need a global CSS file used across all pages and separate CSS files that are used only on a single page.
  • Scripts (JavaScript files)
    • In a separate folder.
• A navigation list (<nav>) shows links to all the pages to be included in the website. Navigation allows the user to navigate between all pages.
• The code should be well-organized and easy to read.
• The website works correctly from the “public” URL (GitHub Pages).

UI / UX

• Did the team put thought into the user experience?
• How well-designed is the interface?
• How is the CSS code written?
• Is the website responsive?
• Does the website look good on mobile devices?

Pitching

• Did you present as a team?
• Was your presentation engaging?

Challenge fulfillment

• How well did you meet the requirements of the challenge they selected?
• Was the solution innovative?
• Did it solve the problem presented in the challenge description?