Visual Paradigm Desktop | Visual Paradigm Online

Blog46- Page

Example1 month ago

如何利用人工智能驅動的建模軟件構建酒店預訂系統 想像一位使用者試圖理解酒店預訂平台的工作原理——從搜尋房間到完成預訂。若沒有清晰的視覺地圖,整個流程會顯得零散。這正是人工智能驅動的建模軟件發揮作用之處。 這並非關於複雜的工具或技術設置。而是僅需描述系統,就能獲得清晰、逐步的視圖。一個簡單的提示即可生成結構良好的序列圖,不僅展現流程,還揭示潛在風險。 使用者的旅程:從提示到洞見 該使用者是一位負責新酒店預訂功能的產品經理。其團隊需要了解預訂流程在系統中如何運作,更重要的是,找出可能出問題的環節。 他們身邊沒有開發人員可以繪製互動流程。因此,他們轉而使用人工智能驅動的建模工具,發現該工具易於使用且極具直覺性。 他們的目標很簡單:展示使用者如何與系統互動,並識別流程可能失敗的環節。 他們所做的如下: 從明確的提示開始: 為酒店預訂平台創建一個序列圖。 人工智能解讀了該提示,並生成了一個包含關鍵參與者的序列圖:使用者、預訂服務、房間資料庫和支付服務。 該圖顯示了完整的流程: 使用者搜尋房間。 系統檢查房間資料庫中的可用性。 若房間可預訂,系統將進入支付環節。 若支付失敗,系統會通知使用者。 所有路徑——成功、無房可預訂、支付失敗——都得到了清晰的建模。 接著,他們要求進行風險分析: 提供序列圖中可見的潛在瓶頸或風險的概覽。 人工智能不僅展示了流程,還標示出關鍵風險: 資料庫延遲在房間可用性檢查期間可能導致使用者延遲。 支付失敗可能因網路問題或使用者錯誤而發生,導致預訂中斷。 無房可預訂若系統未提供替代方案,可能導致使用者感到挫折。 這不僅僅是一張圖表。它變成了一種診斷工具。 這對現實世界系統的重要性 由人工智慧驅動的模擬軟體不僅僅繪製圖表,還幫助團隊觀察系統在壓力下的運作方式。 在這個範例中,序列圖作為以下內容的基礎: 識別使用者旅程中的弱點 建立更佳的錯誤處理機制 提升系統回應速度

利用視覺範式工具將SWOT洞察轉化為行動計畫 當一位企業領導者審視SWOT分析時,真正的價值不在於列出優勢與威脅,而在於將這些洞察轉化為具體的下一步行動。這種從原始數據轉化為戰略方向的過程,正是視覺範式等工具的優勢所在。透過AI驅動的商業策略建模,整個流程變得高效、結構化且直觀易懂。 傳統的SWOT分析往往僅止於列出觀察結果。真正的挑戰在於將這些要素與實際的工作流程、改進措施或風險緩解方案聯繫起來。視覺範式透過讓使用者超越簡單的分類,從SWOT資料中生成清晰且可執行的圖表,來彌補這一缺口。這不僅僅是整理資訊,更是讓資訊真正動起來。 為何SWOT分析需要的不只是清單 SWOT分析包含四個部分:優勢、弱點、機會與威脅。雖然具有參考價值,但當與團隊分享時,往往仍停留在靜態狀態。若缺乏視覺結構,這些洞察難以理解或進一步發展。 例如,一家新創公司可能將「強大的社群參與」視為優勢。但若缺乏明確的路徑,這一洞察便無法引導出擴展當地活動或建立推薦計畫等決策。同樣地,對於「日益增長的數位需求」等機會而言,若缺乏視覺化的架構,很難規劃出具體的行動方案或資源需求。 這正是AI驅動的商業策略建模所能帶來的價值所在。使用者不再僅依賴試算表或筆記,而是能從SWOT生成流程圖,將機會對應至行動計畫,並將弱點連結至緩解策略,全部以視覺化形式呈現。 視覺範式如何將SWOT轉化為可執行的模型 視覺範式的AI聊天機器人扮演著戰略思考與執行之間的橋樑。使用者描述其業務背景——他們擅長的事項、面臨的困難、未來的趨勢以及潛在威脅——AI則根據這些輸入生成結構化的模型。 想像一位零售店老闆正在評估自己的業務。他們描述: 優勢:鄰近地區人潮眾多,擁有忠實的客戶群。 弱點:線上存在感有限,庫存週轉緩慢。 機會:電商需求上升,新配送服務出現。 威脅:市場新進競爭者,消費者偏好轉變。 AI解析這些內容後,以圖表形式回傳SWOT分析結果,並進一步轉化為明確的行動計畫。該工具可生成流程圖,顯示每個機會如何連結至可衡量的行動方案,例如推出網站或改善供應鏈流程。 這不僅僅是將SWOT分析轉化為行動計畫,更是一步步將戰略要素轉化為營運圖表的過程。 支援戰略決策的圖表 視覺範式的AI聊天機器人支援多種建模標準,有助於建立戰略清晰度: SWOT分析 – 以具明確連結的矩陣形式呈現。 PEST/PESTLE – 用於評估宏觀環境風險

UML1 month ago

從狀態圖到設計模式:您的AI生成圖表如何引導至狀態設計模式的實現 在設計軟體系統時,開發人員通常會從一個狀態圖來模擬實體如何在不同階段之間轉換。但將狀態圖轉換為具體的設計模式(例如狀態模式或策略模式)需要兼具領域洞察力與建模紀律。這正是AI驅動的建模軟體發揮作用之處,它在高階行為與可重用的設計解決方案之間提供了一個實用的橋樑。 現代的建模工具越來越依賴AI來解讀自然語言輸入並生成準確的視覺化呈現。具備AIUML聊天機器人可以根據系統行為的描述,在幾秒內生成狀態圖。接著,同一個AI可以協助識別哪種設計模式最適合圖中所定義的轉換與條件。 本文評估了此類工具如何支援從狀態圖到設計模式實現的整個過程。文章著重於實際應用案例、自然語言轉換為圖表的價值,以及為何AI驅動的建模軟體優於傳統的手動方法。 為什麼狀態圖是起點 狀態圖是物件導向設計中的基礎元素。它捕捉物件或系統的生命周期,定義其可能處於的狀態,以及觸發轉換的事件或條件。 例如,「付款處理器」可能會經歷如下狀態:待處理, 處理中, 失敗,以及已完成。開發人員可能以白話描述此行為: 「付款請求從待處理狀態開始。若使用者提交請求,則進入處理中狀態。若付款成功,則轉至已完成狀態。若處理後失敗,則轉至失敗狀態。」 用於繪圖的AI聊天機器人會解讀此輸入,並生成一個乾淨且符合標準的狀態圖——包含轉換、狀態標籤以及進入/退出條件——且無需事先具備UML知識。 這正是自然語言轉換為圖表轉換的威力。它消除了正式符號的障礙,讓領域專家能在設計決策做出之前,率先定義行為。 AI驅動的建模軟體:通往設計模式的橋樑 大多數傳統建模工具要求使用者手動定義狀態與轉換。此過程可能耗時且容易出錯,特別是在處理複雜行為或邊界情況時。 AI驅動的建模軟體,例如AI UML聊天機器人,改變了這一切。使用者不再需要繪製線條與方框,而是描述系統行為,AI便會生成符合UML標準的狀態圖。 一旦圖表建立完成,AI便可分析轉換,並建議是否採用如狀態 或 策略會是更合適的選擇。 例如: 「付款系統具有多個狀態,每個狀態都有不同的行為。當付款處於待處理狀態時,系統會等待。當處理中時,會呼叫外部服務。若失敗,則會重試或中止。」 AI 檢測到行為會根據內部狀態而改變,並建議使用狀態模式作為解決方案。它解釋原因:「狀態模式封裝了與狀態相關的行為,允許每個狀態定義轉換方式以及如何

UML1 month ago

僅用一個提示將使用者故事轉換為 UML 類圖 想像你是一家新創公司的產品經理。你的團隊剛完成一個衝刺。你有一堆使用者故事——簡單、人性化的語句,例如「作為一位顧客,我希望能夠重設我的密碼」 或「作為一位使用者,我希望能夠更新我的個人檔案」。它們很清晰,但卻無法對應到任何技術內容。沒有類別,沒有關係,也沒有結構。 這就是問題所在。這些故事描述的是什麼人們想要的內容,而不是如何軟體應該如何建構。若缺乏使用者聲音與程式碼之間的橋樑,團隊將面臨建構出不符合真實需求的功能的風險——更糟的是,建構出彼此無法溝通的系統。 現在進入那個單一提示改變一切的時刻。 使用者故事開口說話的那一天 艾蓮娜是產品經理,她坐在書桌前,手邊是一本寫滿故事的筆記本。她不知道該如何將這些故事轉換成一個類圖。她曾見過別人這麼做——有些人用試算表,有些人用手繪草圖——但沒有一種方式讓人覺得系統化或快速。 她打開瀏覽器,輸入: 「將這些使用者故事轉換為一個UML類圖: 作為一位顧客,我希望能夠重設我的密碼。 作為一位使用者,我希望能夠更新我的個人檔案。 作為一位使用者,我希望能夠檢視我的訂單歷史。 作為一位使用者,我希望能夠下一個新訂單。」 她按下送出。 不到 30 秒,一個乾淨的 UML 類圖出現了——顯示出像顧客, 訂單, 個人檔案,以及密碼重置。它包含了屬性、方法,以及一個簡單的關係,顯示了客戶下了一筆訂單,並更新其個人檔案. Elena 不需要寫任何一行程式碼。她不需要從資料庫中提取資料,也不需要猜測需要哪些類別。AI 理解了每個故事背後的意圖,並將其轉化為結構化的模型。 這不是魔法。這是基於提示的圖形生成技術即時運作。 這在實際專案中為何如此重要 在敏捷開發中,使用者故事是基礎。它們是團隊理解客戶需求的方式。但它們並非軟體的藍圖。 團隊經常跳過建模階段——不是因為他們不知道該怎麼做,就是因為他們認為圖表是專家才會用的。

一家小型科技新創公司如何運用SOAR分析推出新產品 在推出新應用程式之前,一家小型軟體新創公司苦於無法讓團隊對齊共同願景。創辦人有一個好點子——一種幫助小型企業自動化日常任務的工具——但他們無法清楚定義問題、解決方案,或其在市場中的定位。會議不斷延續,團隊成員各自提出不同觀點,沒有人能說出:「我們正在打造的是這個。」 某個晚上,CEO坐下來與一位同事說:「如果我們試著把這一切畫出來呢?不用投影片或試算表,而是用一種清晰、直觀的結構?」 就在那一刻,他們轉而使用由人工智慧驅動的模擬工具。他們不需要是商業架構的專家,只需描述當下的情況即可。 什麼是SOAR分析——以及它在專案啟動中為何重要 SOAR代表優勢、機會、風險與改進領域。這是一個簡單卻強大的框架,能幫助組織釐清當前狀態,並找出前進的方向。 在專案啟動或新產品構想階段,SOAR分析能協助團隊: 識別可加以利用的內部優勢 發現市場所提供的外部機會 在問題發生前就識別潛在風險 了解現有流程中需要改進之處 它能將模糊的想法轉化為結構化的洞察。這種清晰度在推出新產品時至關重要。 傳統的SOAR分析需要團隊手動建立圖表,過程中常有大量反覆討論。這個過程可能耗時數小時,卻仍可能留下理解上的盲點。 透過人工智慧聊天機器人進行視覺化建模,團隊可以描述其情境——例如「我們正在推出一款針對小型診所的任務自動化工具」——並在數分鐘內獲得完整的SOAR分析。 真實場景:運作方式 認識一下Maya,她是新創公司ClinixFlow的創辦人。她直覺認為小型醫療機構需要一款工具來自動化預約排程與後續追蹤。但她不知道自己的點子是否可行,也不清楚該如何向投資人呈現。 她沒有從投影片或假設開始,而是打開了人工智慧視覺化建模聊天機器人,並說: 「請幫我為小型診所設計一款排程自動化工具的SOAR分析。」 工具立即回應,並提供一份清晰的SOAR圖表。優勢顯而易見:現有的診所員工花費大量時間進行手動排程。機會何在?大型診所已開始使用數位工具,但小型診所仍被落後。風險包括對資料隱私的擔憂,以及習慣紙本作業的員工產生抗拒。需要改進之處則包括與現有電子病歷系統缺乏整合。 Maya不僅獲得一串點狀清單,更看到這些要素以視覺化方式相互連結。她現在能自信地向團隊與投資人闡述這個願景。 她不需要知道SOAR的精確規則或如何建模。人工智慧已根據她的描述完成一切。 為什麼

UML1 month ago

從商業需求到類圖:人工智慧如何彌合差距 想像你是一家中小型軟體公司的產品經理。你的團隊剛剛收集了使用者的反饋:客戶希望有更快的結帳流程、更好的訂單追蹤,以及更簡單的退貨管理方式。你需要將這些想法轉化為開發人員能夠理解的清晰且結構化的模型。你該如何從一串想法轉化為技術圖表? 使用傳統工具時,這個過程耗時良久——會議、文件編寫、手動繪製。但現在,你只需幾句話,就能在幾秒內獲得專業的類圖在幾秒內。這正是人工智慧驅動的建模軟體的用武之地。 它聆聽你的言語,理解其含義,然後建立反映你商業需求的模型——無需程式碼,也無需設計技能。 這並非魔法,而是一種真實且實用的工具,能將自然語言轉化為結構化的視覺模型。當你試圖將商業需求映射到技術設計時,它尤其有效。 為什麼人工智慧圖表繪製對現實專案有道理 在數位工具出現之前,將商業需求轉化為軟體設計意味著冗長的會議、手繪草圖,以及大量的反覆討論。如今,團隊可以用簡單語言描述一個系統,並在幾分鐘內獲得精確的呈現——例如類圖。 這正是人工智慧圖表繪製所做的事情。你不再需要依賴專家來解讀需求,而是可以直接與系統對話。人工智慧聆聽、理解,並生成符合你描述的模型。 例如,如果你說: 「我們需要一個系統來追蹤訂單、處理客戶退貨,並在貨物延遲時通知使用者。」 人工智慧理解你描述的是具有三個關鍵組件的系統:訂單管理、退貨處理與貨物通知。接著,它會建立一個類圖,包含相關的類別,例如訂單, 退貨, 貨物,以及它們之間的關係——例如依賴或關聯。 這種清晰度能消除混淆。它幫助開發人員、產品團隊和利益相關者都能看到相同的模型——而無需了解UML或軟體設計。 如何使用人工智慧從文字生成類圖 讓我們走一遍真實情境——無需專業術語,也無需設定。 情境:一家零售新創公司希望建立一個系統來管理其庫存與訂單履行。創辦人表示: 「我們需要追蹤產品、訂單與退貨。當客戶退貨時,我們需要更新庫存、記錄退貨,並發送確認郵件。」 你不需要了解UML。你只需要用簡單的語言描述問題。 你打開位於 chat.visual-paradigm.com的AI聊天機器人。你輸入: 「根據文字生成類圖:我們需要追蹤產品、訂單和退貨。當客戶退貨時,我們需要更新庫存、記錄退貨並發送確認郵件。」 AI會回應一個乾淨、專業的類圖。它包含: 一個 Product類,包含名稱和庫存等屬性 一個 Order類,與一個

非架構師的 ArchiMate:企業架構簡明入門 什麼是 ArchiMate,它為什麼重要? ArchiMate 是一種基於標準的語言,旨在以結構化且可互通的方式呈現企業架構 結構化且可互通的方式。由國際系統工程學會(I²SE)開發,它提供了一個框架,用以描述組織不同層級之間的關係:人員、流程、資訊與技術。與更抽象或視覺化的建模方法不同,ArchiMate 透過一組預定的觀點,將關鍵領域(如業務、應用與技術)映射至一個一致的模型中。 這門語言建立在本體論原則之上,其中實體被分類並透過語義關係相互連結。例如,一項業務能力(如「客戶服務」)可能透過技術系統(如 CRM 平台)實現,而該系統又支援特定流程(例如「處理詢問」)。這些連結構成了一個反映組織內實際價值流動的模型。 由於 ArchiMate 對新手而言並非直覺易懂,其應用歷來僅限於企業架構師與 IT 專家。然而,近期人工智慧驅動的建模技術進步,已開始降低入門門檻。目前的工具支援自然語言輸入以生成 ArchiMate 圖表,讓使用者能以白話描述系統,並獲得結構完整且符合規範的輸出結果。 人工智慧驅動的 ArchiMate 建模:實務上的轉變 傳統企業建模需要深厚的領域知識以及對正式符號的熟悉。人工智慧在視覺化建模中的出現,帶來了一種新典範:從文字描述中生成符合規範且標準化的圖表。 例如,一位分析大學運作的學生可能會這樣描述: 「大學提供線上學位課程。每個課程透過學習管理系統進行授課。學生透過入口網站存取內容,課程成果則透過學生資訊系統進行追蹤。」 一個人工智慧驅動的工具可以解析此描述,並生成一個有效的 ArchiMate 模型,其中包含適當的元素,例如: 業務領域(例如:「教育交付」) 應用組件(例如:「LMS」、「學生入口網站」) 技術基礎設施(例如:「雲端主機」、「資料庫伺服器」)

UML1 month ago

提升軟體架構:結合AI的UML組件圖之強大功能 設計穩健且可維護的軟體架構是任何成功開發專案的基礎任務。在架構師工具箱中的眾多工具中,UML組件圖突出顯示為規劃系統結構不可或缺的視覺輔助工具。但如果這個複雜的過程能透過智慧協助大幅簡化並加速,會如何?這正是Visual Paradigm的AI驅動的建模軟體重新定義了架構設計的格局。 什麼是UML組件圖? 一個UML組件圖是統一模型語言(UML)一種結構圖,用於展示系統中組件的結構及其相互依賴關係。組件是系統中模組化且可替換的單元,封裝了一組介面並提供功能。此圖能有效展示高階系統組件之間的互動,提供清晰的架構藍圖。 在軟體架構中何時應使用UML組件圖 組件圖在軟體開發生命週期的各個階段都至關重要,特別是在您需要: 設計模組化系統:將複雜系統分解為更小、可管理且可交換的組件。這對於分散式系統、微服務架構以及大型應用程式至關重要。 理解現有架構:透過繪製核心組件及其關係,分析繼承或未文件化的系統。這有助於重構工作或系統改進。 規劃可重用性:識別可跨系統不同部分甚至全新專案重用的組件,促進效率與一致性。 傳達架構願景:向利益相關者、開發人員和品質保證團隊清晰闡述系統的高階結構,確保各方對各部分如何整合有共同理解。 管理依賴關係:視覺化組件之間的關係與依賴關係,協助識別潛在的耦合問題,並引導設計決策以降低系統脆弱性。 整合第三方系統:模擬外部組件或服務如何與您的內部架構整合,定義所需的介面與資料流。 元件圖繪製的傳統障礙 從歷史來看,建立和維護 UML 元件圖一直是一項耗時且經常需要細心處理的過程。架構師和開發人員經常面臨: 手動操作:在一般的圖示工具中手動繪製元件、介面和依賴關係,需要大量時間並嚴格遵守 UML 語法。 一致性挑戰:確保所有元件正確遵循 UML 標準,並在大型圖示中維持一致性,可能十分困難。 迭代開銷:隨著需求演變而修改圖示可能十分乏味,導致文件過時或不一致。 缺乏情境智慧:傳統工具本身無法理解架構情境,導致使用者必須手動解讀並應用最佳實務。 Visual Paradigm:AI 驅動建模軟體的前沿 Visual Paradigm

UML1 month ago

解鎖一個「改變遊戲規則」的功能:如何利用人工智慧建模遊戲狀態 遊戲開發者經常面臨一個挑戰,即釐清遊戲內部狀態轉換的運作方式。這對遊戲流程、玩家行為和系統邏輯至關重要。傳統上,這需要手動繪製UML狀態圖——耗時、容易出錯,且需要深厚的建模經驗。 人工智慧驅動的建模軟體的出現,使這一過程變得更加容易取得。其中一個突出的工具是AI UML聊天機器人。僅需自然語言輸入,使用者即可為遊戲生成完整的狀態圖,無需先前的圖示繪製專業知識。 本文探討如何利用人工智慧來建模遊戲的狀態轉換——特別是使用能理解上下文、支援自然語言遊戲建模,並產出準確且標準化輸出的AI圖示生成器。 為何傳統遊戲狀態建模存在不足 建立一個狀態圖為像賽車模擬器或角色扮演遊戲之類的遊戲建立狀態圖,需要追蹤許多玩家狀態:遊戲內時間、天氣、玩家生命值、車輛狀態、物品清單或任務進度。 傳統建模工具要求開發者: 定義有限的狀態與轉換集合。 使用精確的術語與UML語法。 手動繪製每個元素並驗證流程。 這些障礙對獨立團隊或缺乏正式訓練的新手開發者而言尤其高。即使是有經驗的設計師,也常覺得這個過程枯燥乏味,容易遺漏邊界情況或產生無效的轉換。 人工智慧驅動的建模軟體改變了這一切。開發者不再需要從空白畫布開始,而是用白話描述遊戲行為,系統便能將其轉化為清晰且正確的圖示。 AI UML聊天機器人如何簡化狀態建模 AI UML聊天機器人使用專門針對視覺化建模標準(包括UML狀態圖)訓練過的模型。它能理解遊戲邏輯,並能解讀自然語言描述。 例如: 「我想要建模一款太空冒險遊戲的狀態轉換,玩家可以處於閒置、探索、戰鬥或逃脫狀態。當他們看到威脅時,會進入戰鬥狀態。如果找到安全區域,就會回到閒置狀態。如果失去全部生命值,則會進入逃脫模式,然後重新開始。」 人工智慧會解讀這段描述,並生成一個清晰且有效的UML狀態圖,包含: 明確的狀態 正確的轉換 進入/離開條件 自然的流程 這不僅僅是一張草圖——而是一個結構完整、符合標準的模型,可用於後續開發或文件編撰。 實際應用案例:一款行動遊戲益智遊戲 想像一款行動益智遊戲,玩家可以: 開始一關 解決一個謎題 獲得提示

如何使用人工智能為利益相關者總結您的圖表 主要問題的簡明答案 人工智能圖表總結涉及使用自然語言處理來解讀圖表中的視覺元素,並產生清晰、簡明的結構與意圖說明。由人工智能驅動的工具可以從圖表中提取關鍵組件、關係與商業邏輯,並以通俗語言呈現,使非技術性利益相關者也能輕易理解。 什麼是人工智能圖表總結? 人工智能圖表總結是將視覺化建模成果(例如UML, ArchiMate,或C4 圖表)轉化為人類可讀的摘要。這些摘要解釋圖表的目的、結構與關鍵組件,使利益相關者即使沒有建模專業知識,也能理解複雜的系統設計。 與傳統手動撰寫的文件不同,後者常導致內容不完整或過於簡化,人工智能驅動的總結會分析圖表的元素、連接與註解,生成準確且具上下文意識的敘述。此能力在跨功能團隊中尤為重要,因為工程師、業務分析師與高階主管必須建立共識。 何時使用人工智能驅動的圖表總結 人工智能驅動的總結在以下情境中效果最佳: 在利益相關者簡報期間:當向高階主管展示系統架構圖時,人工智能可生成摘要,突出顯示關鍵組件、依賴關係與決策點。 在建模會議後:團隊經常製作詳細圖表,但缺乏時間加以說明。人工智能可立即將視覺內容轉化為可操作的洞察。 用於合規性或審計審查:摘要作為圖表意圖的文字紀錄,有助於追蹤與責任歸屬。 在協作環境中:當團隊成員具備不同層次的建模知識時,人工智能可確保每位成員獲得一致且易於理解的說明。 人工智能圖表總結的技術基礎 該過程依賴多項先進的人工智能能力: 視覺模式識別:人工智能可偵測符合建模標準的特定形狀、標籤、連接線與版面模式(例如 UML 類圖、C4 上下文圖)。 語義解讀:它能理解元素背後的含義——例如,C4 圖中的「部署節點」代表一個實體實例。 自然語言生成(NLG):該工具將結構化資料轉換為連貫的文本,並在相關情況下使用領域專用術語。 情境感知的解釋:摘要包含關係,例如「此組件依賴資料庫」或「此業務流程觸發通知」。 這些功能是根據現實世界的建模標準訓練而成,確保在以下領域中具備準確性:企業架構、軟體設計與商業策略。 現實應用:一個實際案例 想像一個軟體團隊正在設計一個新的電子商務平台。他們建立了一個UML順序圖,顯示使用者結帳互動。該圖包含參與者、訊息、物件與條件流程。 專案經理需要向非技術背景的投資人解釋結帳流程。他們並未直接展示完整圖表,而是使用人工智慧生成摘要: 「此圖表顯示端到端

Loading

Signing-in 3 seconds...

Signing-up 3 seconds...