polymatic.art – Daniel Pakos

blending science, technology and art

Blog

  • First day in Dubai

    First day in Dubai

    “O’ Nadda, Nadda, Nadda
    When roses are blooming on her cheek
    And if they refuse to give you to me
    I will tear down the high mountains.”

    On returning to London, I planned a one-day stop in Dubai. After a few weeks in India, I arrived in a city known for its grandeur, which can be felt almost at every step. The variety of architecture and details delights, modern and functional urban solutions satisfies, and the number of attractions to choose from is pampering. But Dubai is also known for its multicultural character, where over 80% of the inhabitants are expatriates, mainly from Middle East, Asia, Africa. In a short period, they built a majestic metropolitan city in the desert, and they proved how impossible it would be to turn to life.

    Despite all these people-friendly amenities, it was somewhat difficult for me to get around here, especially with only one day to explore; my schedule was quite tight. The main attractions on my list were separated from the metro stations by gigantic shopping malls, really gigantic ones. It’s like comparing the Titanic to a cruise ferry in Europe. I didn’t make it to Miracle Gardens on time because it took me over 40 minutes to get through the shopping centre, where I made the wrong turn a few times. I barely reached Burj Khalifa (the tallest building in the world), but it took me over an hour to go through all the checkpoints and queues. Navigating around these gigantic shopping centres is even more difficult because of the multitudes of people who, it looks like, have found a place to rest here. However, they seem not interested in shopping in the present here, mostly in top-class stores. People stroll along these marble corridors between the golden shops like awakened flies in winter – unhurriedly and seemingly – the same as on a Sunday walk in the park. I probably would have fallen into their rhythm to drift with them and feel the atmosphere, but I was in a hurry to watch the sunset… which I ultimately missed -it was already dark when I reached the top – so I just looked up and brushed my fingertips against the much closer moon today

    Source: https://www.instagram.com/p/C4ltXrNSj8X

  • Scale of working together

    Scale of working together

    As far as I can remember, I have never worked alone.

    Even when I started making end-to-end websites as a webmaster, from the very beginning, I involved graphic designers to help me with tasks that took too much time for me, but also to be more motivated, not only in my interactions with clients but also thanks to my collaborators and partners.

    A couple years later, things started to be more complicated. It was the late 2000s and it was the time when early frameworks and CMSes were created. However to be beneficial from these it was one condition – learning new syntax, logic and style to learn on top of any other plain language or technology.

    Spending time to learn anything I could potentially use to speed up with implementation or keep things more consistent was a big investment of time.

    To be honest, it wasn’t always profitable to learn many of these. Later, it became too difficult to understand how the raw language or technology worked, so it was difficult to fill the gaps due to the limited possibilities of a framework or CMSes, and the lack of knowledge and experience in using the limitless nature of the language. So, I kept working with plain languages and anything that, at some point, due to complexity, had been split into more roles like frontend developer, backend developer, DevOps, and many more. This gave a narrower spectrum for developers to learn and master one discipline. Thus, collaboration gained greater importance, where a group of people worked on the same projects, communicating more often to be synchronized with the progress of their part of the project.

    To be motivated and effective at work as an individual, being skilled in one’s own discipline and strictly aligned with one’s responsibilities is, in most cases, not enough to be successful. There are more factors involved in any project – non-technical ones.

    End-to-end communication is the key.

    Everything starts with knowing the goals set by project owners, which often lead to specific implementation plans and technical requirements. Developers are often not involved in discussions about the broader goals, budget, and timelines. Frequently, solutions suggested without input from the development teams are not precise or adequate. This is because decision-makers who do not involve developers, and thus lack technical insight and real-world use cases, may not see all possible solutions. Consequently, the underlying problem is often overlooked, and the focus shifts from collaboratively finding solutions to simply executing the stated technical requirements.

    It’s quite obvious that any requirement is an implication of a problem solution. In most cases, these are business or user-related.

    “Later, as part of the development process, sharing the status of progress and completed functionalities in documentation has a long-term impact on future collaboration and improves the product in a more predictable and effective way.

  • My 20 years of experience and more

    My 20 years of experience and more

    Over the past couple of years, my professional development has increasingly centered on understanding web accessibility and the challenges of its implementation.

    Today, I still recognize how difficult it is to cover all the standards, regulations, and perspectives involved. Web accessibility is like a starry night sky of multitudinous perspectives. Finding the right balance between achieving user-friendly, accessible web projects and the time and budget allocated often fades during communication between an organization’s departments and due to insufficient client engagement, especially with development teams.

    Before I started working in London on a permanent basis, I was a consultant and leader, working directly with clients to support them with their web-based challenges. In most cases, I aimed to make their projects easier for a wider audience to find and to design information architecture that clarified the meaning of the content.

    Looking back at my career, I sometimes think that I was more like a developer with a disability when it came to prioritizing effort and workload for the functional and non-functional (including web accessibility) aspects of projects.

    Now, with 20 years of experience in web development—gained knowledge and intuition from working on various, diverse projects, and having great support from experts and partners—I have decided once again to support other initiatives of people for whom values related especially to web accessibility are most important.