الکامپ

بیست‌ونهمین نمایشگاه بین‌المللی الکامپ در هفته دوم شهریورماه برگزار خواهد شد؛ رویدادی که به‌عنوان بزرگ‌ترین گردهمایی سالانه صنعت فناوری اطلاعات و ارتباطات کشور، نقش محوری این حوزه در توسعه ملی را برجسته می‌کند.

بر اساس اعلام روابط عمومی این رویداد، پیش‌ثبت‌نام الکامپ ۲۹ از ۱۶ خردادماه آغاز شده و شرکت‌ها، سازمان‌ها و فعالان حوزه‌های فناوری اطلاعات، ارتباطات، اقتصاد دیجیتال، امنیت سایبری، هوش مصنوعی، نرم‌افزار، سخت‌افزار، خدمات دیجیتال و استارتاپ‌ها می‌توانند برای حضور در این نمایشگاه اقدام کنند.

الکامپ ۲۹ با حضور گسترده شرکت‌های خصوصی، مجموعه‌های دولتی، نخبگان و متخصصان، بار دیگر ظرفیت‌های داخلی و توان ملی اکوسیستم فناوری ایران را به نمایش خواهد گذاشت. این رویداد با هدف ارائه دستاوردهای نوآورانه، معرفی محصولات و خدمات جدید و تقویت همکاری‌های فناورانه میان بخش‌های مختلف کشور برگزار می‌شود.

در شرایطی که فناوری به یکی از اصلی‌ترین ابزارهای توسعه کشورها تبدیل شده، الکامپ ۲۹ نمادی از اراده جمعی صنعت فناوری ایران برای مشارکت در ساخت آینده‌ای پایدار، هوشمند و مبتنی بر نوآوری است.

 ELECOMP 29 

The 29th International ELECOMP Exhibition is set to take place in the second week of Shahrivar, reaffirming its position as Iran’s largest annual gathering for the ICT and digital technology sector. Despite the sensitive regional climate and ongoing threats, Iran’s technology industry continues to demonstrate its resilience and readiness to contribute to national development and reconstruction.

According to the event’s Public Relations Office, pre‑registration for ELECOMP 29 began on 16 Khordad, enabling companies, organizations, and professionals across information technology, communications, digital economy, cybersecurity, artificial intelligence, software, hardware, digital services, and startups to secure their participation.

ELECOMP 29 will once again host a wide spectrum of private companies, government organizations, experts, and innovators showcasing the nation’s internal capabilities, technological strength, and collective confidence. The exhibition aims to highlight cutting‑edge achievements, introduce new products and services, and strengthen cooperation across the country’s technology ecosystem.

At a time when technology has become a central driver of national development, ELECOMP 29 stands as a symbol of the collective determination of Iran’s tech community to build a smarter, more sustainable, and innovation‑driven future.

The brand systems we wish more founders understood

Most founders who come to us with “we need a brand refresh” describe the problem as a logo problem. Sometimes it is. More often the logo is fine and the system around it is missing. Without the system, every new asset is an improvisation, and improvisation at scale produces the inconsistency the founder is reacting to.

The four components every brand system needs

One: a typography hierarchy with three levels at most. Display, body, micro. Each with a defined weight, line height, and use case. Without this, every layout is an argument.

Two: a color system with primary, secondary, semantic, and neutral roles. Each with hex, HSL, RGB, and accessibility-tested contrast pairings. Without this, the marketing site looks different from the product UI which looks different from the deck.

Three: a motion vocabulary. How does this brand enter? Exit? Hover? Focus? If you cannot answer those questions, the brand falls apart the moment anything moves — which is everywhere on the modern web.

Four: a voice document. Three to five tonal principles, written sentences that demonstrate them, three to five anti-patterns. Without this, the brand sounds different in every channel because every author is inventing the voice from scratch.

The system as document

None of this is theoretical. It is a 30-to-50 page document. It includes pixel-perfect type specs and live-coded tokens. It includes ten written exemplar paragraphs in the brand voice. It includes a motion library video, twenty seconds long, that shows entrance and exit principles in motion. It is a deliverable, not a vibe.

If you commissioned a brand and you got a logo file and a one-page color palette, you got a logo. You did not get a brand system. The next person to design something for you will improvise. The improvisations will not match. That is the inconsistency you’re reacting to.

وب وایتال‌ها یک تحویل‌دادنی هستند، نه یک کار بعد از طراحی

وب وایتال‌ها یک تحویل‌دادنی هستند، نه یک کار بعد از طراحی

بزرگ‌ترین دلیل کند بودن سایت‌ها، تصمیم‌های طراحی بدون محدودیت عملکرد است

بزرگ‌ترین عامل کندی سایت‌ها، تصمیم‌های طراحی‌ای هستند که بدون درنظر گرفتن محدودیت‌های عملکرد گرفته می‌شوند. ویدئوی هیرویی که هیچ‌کس به آن ایراد نگرفت. ست فونتی با هفت وزن مختلف. لندینگ‌پیجی با سی بخش و یک تصویر پارالاکس برای هر بخش.

هر تصمیم، دویست میلی‌ثانیه اضافه می‌کند. تا زمانی که سایت به مرحلهٔ تولید برسد، صفحه پنج ثانیه هزینه دارد.

 

محدودیت، خودِ طراحی است

ما LCP، CLS و INP را به‌عنوان محدودیت‌های طراحی درنظر می‌گیریم — نه مشکلاتی که تیم فنی باید بعداً اصلاح کند. یعنی: قبل از اینکه طرح را به تیم توسعه تحویل بدهیم، دقیقاً می‌دانیم:

  • عنصر LCP چیست

  • وزنش چقدر است

  • و بودجهٔ عملکرد برای بقیهٔ صفحه چقدر است

این کار خسته‌کننده به‌نظر می‌رسد. واقعاً هم خسته‌کننده است. اما همین دلیل است که سایت‌های ما

روز اول لانچ، هر سه Web Vital را سبز تحویل می‌دهند  نه اینکه بعد از لانچ، شش هفته زمان برای بهینه‌سازی لازم باشد.

 

جایگزین‌هایی که از همان ابتدا انجام می‌دهیم

  • ویدئوی هیرو → WebP متحرک با یک‌دهم حجم، همراه با یک تصویر پوستر به‌عنوان LCP

  • انیمیشن ۶۰ فریم → انیمیشن CSS که به prefers-reduced-motion احترام می‌گذارد

  • فونت با وزن‌های 100 تا 900 → فونت متغیر با دو محور وزن

  • بخش‌های تصویری سنگین → تصاویر بالای صفحه preload، تصاویر پایین صفحه lazy-load با قابلیت بومی مرورگر

 

چرا این موضوع فراتر از Lighthouse اهمیت دارد

اهمیت این موضوع فقط این نیست که گوگل سایت‌های سریع را در جستجو بهتر نمایش می‌دهد — این کار را می‌کند، اما دلیل مهم‌تر این است که سایت‌های سریع تبدیل می‌کنند.

لندینگ‌پیجی که سه ثانیه طول می‌کشد تا قابل تعامل شود، ۳۰٪ از ترافیک موبایل را قبل از اینکه کاربر حتی یک تصمیم دربارهٔ برند بگیرد، از دست می‌دهد.

زیباترین صفحهٔ طراحی‌شده اگر کند باشد، دیگر یک صفحهٔ زیبا نیست.

یک صفحهٔ کند است که هیچ‌کس آن را ندید.

 

 

Web Vitals are a deliverable, not an afterthought

The single largest cause of slow websites is design choices made without performance constraints in the room. The hero

video that nobody flagged. The custom font set with seven weights. The thirty-section landing page with a parallax background image per section. Each decision adds two hundred milliseconds. By production, the page costs five seconds.

The constraint is the design

We treat Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint as design constraints  not engineering remediations. That means: before we ship a design to the build team, we know what the LCP element will be, what its weight is, and what the budget is for everything else.

This sounds tedious. It is tedious. It is also the reason our shipped sites land in green for all three Core Web Vitals on launch day, instead of needing a six-week post-launch optimization sprint.

The substitutions we make on the way in

Hero video → animated WebP at 1/10 the file size, with a poster image as the LCP element. Sixty-fps motion → CSS-driven animation that respects prefers-reduced-motion. Font weight 100, 200, 300, 400, 500, 600, 700, 800, 900 → variable font axis with two ranges defined. Image-heavy editorial sections → above-the-fold images preloaded, below-the-fold lazy-loaded with native browser support, no external library required.

Why this matters beyond Lighthouse

The reason this matters is not that Google rewards fast sites in search. It does, but the bigger reason is that fast sites convert. A landing page that takes three seconds to interact loses 30% of mobile traffic before a single brand decision is made. The most beautifully designed page that is too slow to use is not a beautifully designed page. It is a slow page that nobody saw.

Motion design isn’t decoration — it’s hierarchy

Motion in interfaces and brand work is treated, almost universally, as decorative. Add a fade. Animate the hover. Make it smoother. None of these are wrong, but they describe motion as polish on a finished thing. We treat motion as a hierarchy tool.

What motion communicates

An element that animates in is more important than an element that appears statically. An element that animates with a 600ms ease is more important than one that animates with a 150ms snap. An element that originates from another element is causally related to it; an element that fades in independently is not.

Every motion choice answers a hierarchy question. What enters first? Why? What is the user supposed to look at as the page settles? Where is the click going to take them? Animation telegraphs the answers. Static design has to encode them in space, weight, and color alone.

The constraints we follow

One: motion should respect prefers-reduced-motion. Always. There is no exception. If your animation breaks the experience for users with vestibular conditions, your animation is the bug, not the user.

Two: nothing animates above 800ms. Nothing. Even cinematic transitions. If a motion takes longer, it is no longer felt as motion — it is felt as waiting.

Three: ease curves are not aesthetic, they are physical. Material moves with weight. A cubic-bezier(0.32, 0.72, 0, 1) feels right for most UI; a linear motion almost never does. We pick from a library of five curves and reuse them ruthlessly across the system.

The final test

Turn off the motion. Does the design still communicate the hierarchy? It should. Motion accelerates and reinforces hierarchy; it does not create it. If the static layout works, the motion makes it sing. If the static layout doesn’t work, no amount of animation will save it.