This site is best viewed in a modern browser with JavaScript enabled.

Akira Development

Alecaddd

I'm starting this thread to share my ideas, clarify some points, and overall help myself understand better the process and reasons behind the development choices for Akira.
Let's start with some questions I got from random users online.

Why Linux?

As I always said, Linux is perfect for developers, kinda terrible for designers.
On Linux, we're currently missing a modern, professional, and reliable UX Design App to create complex multi-artboards UI.
You can pretty much do everything on Linux, and the gap between OSs is slowly closing.
For Video Editing you can use the stable Kdenlive, or OpenShot, recently capable of handling 4k videos pretty smoothly.
For 3D and Post Production, there's Blender. And even if you're not on Linux you should use it because it's freaking awesome.
For Digital Painting, there's Krita, constantly developed with a vibrant community. Their brush engine is mind blowing.
Photo editing and manipulation, and Vector Art are the weakest fields on Linux right now. Gimp and Inkscape have a reaaaaaaly slow development roadmap, the UI is outdated, and I keep experiencing crashes when dealing with medium size projects, not even big, just slightly bigger than normal.

Why not forking or contributing to an existing project?

Because learning another approach and getting confident with a software written by other developers is longer than starting something from scratch.
I looked into that, I forked different software, tried to setup my workflow to improve and implement add-ons and new features, but it wasn't really working. Most of these apps have been around for 10+ years, and you can see it in the source code. Legacy, outdated code is one of the main reason of the slow development roadmap. Technology and scripting languages have been evolved so much lately, that using old code or refactoring something written many years ago seems like a waste of time.

Why using Qt and not something else?

Because Qt is fast, stable, multi-platform, and come with its own IDE and Designer editor for quick visual prototyping.
The scripting language is really similar to C++, which I'm slightly familiar with, and their documentation is broad and well written.
I know I could go with other hundreds of different solutions and languages, but I feel like Qt can give me the flexibility and stability to smoothly run my application in every distribution, and if necessary, also release versions for Windows or MacOS.

Where can we see/use the first demo?

I'm currently designing the entire UI from scratch, and I don't want to leave anything for granted, so I'm spending a lot of time in defining every little detail to be as consistent as possible in the final product.
The current, hypothetical roadmap is the following:

July 30th: Complete the UI
August 30th: Release Alpha
September 30th: Release Beta
October/November: v1.0 Release

Why are you designing a new UI and not use a native UI from a distribution?

Because I want my app to be visually consistent with every distribution.
I'm aware this will probably be an unpopular decision, and the final look of the App will not be as native as you thought it would, but making a native app that looks native with every Distro or Desktop Environment, would be insane.
Defining a clean and fresh UI will help me to avoid issues in adapting or creating different versions for different distros. I know probably the main window will look weird, wrapped around whatever window manager will be in place on your distro, but at least the App UI will look consistent and familiar everywhere.

Will Akira be available as a Snap? Downloadable from a software center, having its own PPA?

I'm not really sure about this, yet.
The main goal for me is having a single source where I can push updates and you can get them immediately.
How many times you downloaded an outdated version of a software from the Ubuntu Software Center, and then manually adding a new PPA to get the latest updates? That's super annoying.

The first coding sprint I'll have will be focused on creating a built-in updates manager, so you can check and get notified of new versions as soon as I push new code to the main repository.

After the first release of the final App, I will look into adding the source or packaging it for different app stores, like the Elementary OS App Center.

How can we help/contribute?

As soon as I start pushing code on Github, you can jump on it and submit your updates and implementations. It's 100% open source, so you can also fork it and create your own version if you want.
For now, would be nice to create some rumors and spread the hype on social media.
I created a couple of hashtags I want to use: #AkiraUX and #LinuxLovesDesigners

Just talk about it, share it with your friends, make other developers aware of this project, and spread the love.

A reliable and professional UX Design App for Linux, is the only thing blocking me to ditch MacOS for good, and I can't wait to do that.

Write down your questions, doubts, and thoughts, and thank you all for the support

Alecaddd

Crazy idea!!!

So, guys and girls, I need your help!
I'm thinking to integrate a built-in version control inside Akira in order to easily connect a specific file to a repository, like on Github or Bitbucket, and having the ability to commit and push file changes to the repo.
Version control for design files...that'd be neat.

Now the question. Which file format should I use?
I was experimenting with the creation of a new file format for Akira, something like .akira or .akr or something like that.

The thing is if I go the route of version control, do you guys know what could be the best format to use? Maybe XML? But then, how's this gonna work with other graphic software?

Help me troubleshoot this thing

retractedcable

Alecaddd The thing is if I go the route of version control, do you guys know what could be the best format to use? Maybe XML? But then, how's this gonna work with other graphic software?

The key thing for version control is to stay text-based. Don't use a binary file format.

As for the specific syntax, XML seems kinda outdated. It's very explicit (requires many characters) and generally a pain for the human eye to parse. I used to be a fan of JSON since it is quite concise and widely supported but that also drawbacks, such as being fragile (one missing comma or closing brace and everything falls apart) and having no support for comments. My new favourite is YAML because it is easy to read, more robust than JSON and supports cool features such as anchors.

Here is a comparison of the various syntaxes (ripped from here):

xml

<?xml version="1.0"?>
<EmpRecord>
  <Employee id="emp01">
    <name>Alex</name>
    <job>Developer</job>
    <skills>python, C/C++, pascal</skills>
  </Employee>
  <Employee id="emp02">
    <name>Bob</name>
    <job>Tester</job>
    <skills>lips, forton, REST APIs</skills>
  </Employee>
</EmpRecord>

json

{
  "EmpRecord": {
    "Employee": [
      {
        "-id": "emp01",
        "name": "Alex",
        "job": "Developer",
        "skills": "python, C/C++, pascal"
      }, {
        "-id": "emp02",
        "name": "Bob",
        "job": "Tester",
        "skills": "lips, forton, REST APIs"
      }
    ]
  }
}

yaml

# Employee records

- Emloyee one:
    name: Alex
    job: Developer
    skills:
      - python
      - C/C++
      - pascal

- Emloyee two:
    name: Bob
    job: Tester
    skills:
      - lisp
      - fortran
      - REST APIs

faisaljanjuah

Alecaddd .akr is better than .akira

bambule

Hmm

I honestly never felt the need for version control in that matter, but maybe cause I don't really work in teams. I am using github more as a backup, in case I screw something and need to roll back.

Design-wise for me, a good "history" tab in the software itself, always has been enough, like the protocol in photoshop.
But, maybe its time to get design things on a new level too, so although I cant really give any tips, I am more than curious what you will make out of this.

And I like .akira more than .akr

julientaq

On the contrary, i'd be happy to have snapshot of previous versions of the design, like states.
THe best would be to go with json, as it would be pretty simple to use those to create applications to go through your design using html + css.

The object model would be a little more complicated, as you have different options: user based? project based?

But a button to save snapshot of the project would be awesome.

r0manas

any news on the development?

Alecaddd

r0manas I've been learning Vala and Gtk for the past 2 months, and I release Sequeler on the AppCenter of elementary OS. I'm officially starting the development of Akira on December 1st, with the goal of releasing the first Alpha with some basic features around December 24th.

r0manas

Congrats on starting official development today!

offtopic: just installed 'Pop_Os' (on my 'oldboy' MackBookPro 5.4) it really is 'kinda' what I was searching for it runs really smoothly. But the thing that irritates me is keyboard shortcuts, I can't seem to find the right configuration for 'Pop_Os' to behave like macos shortcuts (e.g to rename file I want to press F2 or Super+Enter not Fn+F2). Maybie you've encountered smth like that or you just never tried to install linux on mac?

theotix

Firstly thanks a lot for this project, I'm super upper motivated to follow his development as long I want to design UI on linux (I have switch to macos now for using Sketch, but I'm more a linux user).
To answer for your initial question, in my opinion :
- .akira is more explicit and not too long for a format name
- The built-in version control could be a good feature, but IMO it's not the priority (you can use a git repo with a graphical client for example to do that)
- Instead maybe you could focus on super complicated to develop (I think) feature but very useful as a designer : a symbol system.

- For the format to use in the work file, I know that Sketch is using (a pretty messy) XML format, maybe you could look how they doing that (I also heard that was pretty bad documented).

Anyway thanks again and can't wait to see the development !

theotix

My bad Sketch was using json format, but I agree with retractedcable YAML has (IMO) a cleaner synthax

Alecaddd

Thank you so much @theotix and retractedcable for the suggestions.

Right now, I'm building the basic initial things, but the saving file format is important.
I agree with @theotix about the fact that version control is not an important feature at this stage, but I still prefer to start from the beginning with a file format that can accept that, in order to be able to quickly implement it when I want, without rewriting a section from scratch, or break compatibility with older versions.

I'm gonna update this topic soon to pin at the top the roadmap, but for now, this is what I'm looking to achieve for this week:

Basic UI areas (Toolbar, left and right panel, bottom bar)
Hide everything with a simple shortcut (CTRL + .) and show only the canvas
Create Artboards
Create a basic shape (maybe I'll start with a rectangle) nested into Artboards
Basic file save, open recent, save as, prompt to save on quit

Not much, but it's a start.

Cheers,

theotix

Yep it's preferable to have in mind what you want to integrate in a second time.
Wha that's already a lot of work for a week. Good luck o/

julientaq

There are multiple ways of looking at file format:
- how readable they are (although that's something that should be taken care of by the apps)
- how usable they are with different tools (thinks about how html is rendered by multiple browsers)
- size of files and others.

how readable they are this is not something that need to be taken in consideration, as, once again, it's some computer work, unless we need to debug a specific file. And again, this will be rendered easier as the computer will clean the file on opening (think about prettifier and linter tools) to make it readable

how usable they are with different tools: interoperability is the most important thing. If we want user to be able to switch app, or to share some design they've made, they need to be able to use something to show them. This is where json is the best way to go (today). Specially as it's a javascript friendly language, which means that it would be easier to build an open source invision using this format, as it would be simple to reuse the file and set comments on specific element, if the API for the file format is clear enough.
Using XML would also be a good way, but then, going SVG as file format should be the best way to go as you'll be able to open your file in any app (from inkscape to illustrator, and even render it in the browser without any additionnal work). Also, svg tend to be usable in js environment, although it will add a little more work, but both way are good (less readable than js, and more complex if you want to bring version control).
Yaml is not the best for this use case, as the only separator is white space, so it's pretty easy to miss tabs and spaces and break a file with just indentation. Way to dangerous to build upon. And also, you will need a parser to use it on the web, and parser are all different, so you'll force the user to use a specific parser, reducing reusability of your file format.

I know nothing about file size, unless the fact that image/photo will take a lot of space. (captain obvious!). But svgs have svgz (gzip svg). One of the way to look at it is like epub files, which are a renammed zip file with all the content inside which mean less space. Also epub use a manifest file with all the meta data, and link to files in the epub (Something that would be pretting interesting to have in Akira as using the metadata, we could set version controlled comments/discussion system inside the file and in the browser)

Can't wait to use it.

Alecaddd

@julientaq thank you so much for this detailed overview.

I'm leaning towards the JSON format to handle and save the actual .akira file.
I feel comfortable with this file format as I've been working with it for many many years, beign a web developer. It's easy to format and almost universally readable.
As you also suggested, building a web parser to be rendered in the browser would be a breeze.
Also, this format will allow me to create and integrate a thumbnail desktop preview for the OS.

The SVG format option will be avaialbe for sure, but more like an export kind of format. Handling this file format for version control would be too complicated.

Anyway, this is all theoritechal for now, but it's an amazing starting point.
I will keep you posted when I start testing the saving option, which should probably happen this weekend.
Cheers

julientaq

dont mention it

Also, while thinking about creating element on the artboard, it would be interesting to look around at how you can build reusable component and a library of thoses. I know it comes way later, but if you have use cases from the beginning, it's easier to design.

Alecaddd

julientaq yup, that's on the list.
I've almost done building all the basic panels with the shortcut to hide them all and leave only the main canvas visible.
After that, I'll start working on the elements. Every single shape will be a standalone object with its own set of properties. If I can make it work correctly, having those objects stored locally in a reusable library comes almost naturally.
So pumped for it

theotix

So hyped ! Also the possibility of hide some toolbar is a great Idea. It's not possible on Sketch, the soft I currently use on MacOS, and it's a shame, I'm so happy that's implemented on Akira o/

julientaq

sketch has a presentation mode and shortcut to hide sidebar (old memories, i havent used sketch for a while), look:

and cmd + . show the presentation mode, where you have nothing but your content.

Alecaddd

julientaq Yup, I just implemented the shortcut CTRL+. to hide everything except the main canvas, just like the presentation mode of Sketch

julientaq

Alecaddd dont make the same error than sketch which doesnt let you make your own shortcut without using the OS keyboard manager.

let the user choose the shortcut (please )

theotix

Oh thank's @julientaq, good tip yo have here o/