Website institucional LIACC — memória descritiva do projecto

O LIACC foi apresentado em sala de aula como sugestão de cliente. O grupo aceitou a proposta, reconhecendo o interesse pedagógico do caso: uma unidade de investigação com um footprint digital desactualizado, utilizador-alvo com exigências diversas (investigadores, estudantes, indústria, comunidade internacional), e um portfólio de projectos e publicações com elevado potencial de reorganização informacional.

O objectivo de negócio foi formulado como sendo o de entregar um website institucional que funcionasse como montra credível, com navegação clara, ligação cruzada entre entidades (investigadores, projectos, publicações, áreas, linhas temáticas, pólos), SEO optimizado, e uma camada comercial leve (loja institucional). Tendo em conta a dimensão do LIACC e o período de avaliação da UC, foi definida uma fronteira conservadora: MVP navegável e defensável, sem deslocalização da marca oficial.

3.1. Modelo adoptado

O modelo de trabalho adoptado foi Scrum com gestão híbrida: Scrum na fase de planeamento (Product Vision, Product Backlog priorizado, Sprint Goals, Definition of Done) e Kanban na fase de execução (fluxo contínuo de tarefas em Not started → In progress → Done, sem cerimónias diárias dado o contexto).

3.2. Artefactos Scrum produzidos

• Product Vision Statement — documento de enquadramento do cliente no hub Notion.
• Product Backlog — base de dados Notion com 8 epics (E1 Analysis & Research, E2 Information Architecture, E3 Design & Identity, E4 WordPress Setup, E5 Content Migration, E6 Shop / E-Commerce, E7 Performance & SEO, E8 QA & Launch), cada ticket com prioridade (P1–P4), story points e sprint de afectação.
• Sprint Backlog mantido como view filtrada do Product Backlog.
• Definition of Done — feature funcional em desktop e mobile; cross-links verificados; Lighthouse > 80; revisão por pelo menos um elemento; deploy em staging.
• RACI pré-definido para os papéis PO, SM, Frontend e Backend.

3.3. Trabalho individual — reconhecimento

3.4. Cadência

A cadência formal de seis sprints planeada no Notion foi comprimida num ciclo contínuo de execução Kanban, mantendo a Sprint Goal de cada ciclo como objectivo semanal. Todos os tickets do backlog priorizado foram concluídos com excepção dos relativos à camada WordPress (ver §9).

4.1. Postura adoptada

A abordagem adoptada foi a de empresa de consultoria especializada em desenvolvimento web. Nessa qualidade, entendeu-se que a escolha de stack é uma decisão técnica de responsabilidade do prestador, não do cliente: o cliente especifica objectivos de negócio (montra credível, cross-linking, SEO, comércio electrónico leve), enquanto a equipa técnica selecciona a tecnologia mais adequada à entrega defensável desses objectivos.

Esta postura justifica o desvio face à indicação WordPress + E-Goi constante da brief: optou-se por uma stack sobre a qual existe domínio técnico pleno, tanto em fase de construção como em fase de manutenção, garantindo que o MVP seria verdadeiramente funcional e avaliável no período disponível. Numa fase inicial explorou-se uma stack Next.js; optou-se por consolidar tudo num único gerador estático em Python sem dependências, eliminando o toolchain Node e garantindo uma só fonte de verdade auditável (single source of truth).

4.2. Stack entregue

4.3. Justificação da escolha

• Performance. Static Site Generation garante Time To First Byte mínimo, pontuação Lighthouse elevada, e custo de hosting marginal.
• SEO. HTML renderizado em build time é indexado por motores tradicionais e por retrievers de LLM sem dependência de JavaScript.
• Acessibilidade. Controlo integral sobre semântica, landmarks ARIA, tokens de design — não subordinado a temas pré-existentes.
• Manutenção. Código Python legível e conteúdo em dicionários versionáveis; uma só fonte de verdade, auditável em Git, sem toolchain a manter.
• Resistência a vulnerabilidades. Não expõe superfície de ataque PHP/WordPress (plugins, XML-RPC, admin exposto).

4.4. Compatibilidade com a brief

Embora a stack escolhida difira da sugerida na brief, a arquitectura de conteúdo é integralmente portável: os tipos de entidades (Person, Project, Publication, Area, Thematic, Unit, News, Product) mapeiam directamente em Custom Post Types do WordPress com Advanced Custom Fields (ACF); a lista de publicações integra-se com a fonte oficial em liacc.fe.up.pt/publications. Em §9 detalha-se o plano de migração.

5.1. Navegação

A navegação primária foi padronizada num modelo de seis itens — Research, People, Education, News & Events, Collaborate e About — com mega-menus em Research, News & Events, Collaborate e About. Esta topologia replica o denominador comum da arquitectura de informação de centros de investigação de referência (MIT CSAIL, Mila, Max Planck, Alan Turing Institute, INESC TEC), onde as secções de Eventos/Seminários e Careers são quase universais e o rótulo ambíguo «Work» não existe.

A barra utilitária do header concentra Search, My account, Shop (despromovida de item institucional para ícone) e o painel de idioma/tema/tamanho de texto. O presente relatório de projecto — sendo meta-trabalho da unidade curricular — foi retirado da navegação institucional e remetido para a meta-zona no rodapé, mantendo a separação entre a oferta do LIACC e os entregáveis de consultoria. A topologia reduz a dispersão identificada na análise do site actual do LIACC (oito secções em navegação plana).

5.2. Modelo de cross-linking

Todas as entidades do modelo de conteúdo ligam bilateralmente através de um padrão único — Person ↔ Publication ↔ Project ↔ Area ↔ Thematic ↔ Unit. Cada página de detalhe apresenta uma sidebar com as ligações relevantes (content + sidebar pattern), aprovado como padrão de IA durante a Sprint 2 do planeamento Notion.

5.3. Publicações — ligação à fonte oficial

A secção de publicações do site funciona como espelho indexado da fonte canónica. A página de listagem integra um banner explícito com a origem dos dados e ligação directa para liacc.fe.up.pt/publications, preservando a autoridade da fonte.

5.4. Inventário de rotas

• Página inicial & sobre o LIACC
• Índice + 7 páginas de áreas de investigação
• Índice + 7 páginas de linhas temáticas
• Directório (espelho de 195 membros) + 11 perfis curados
• Índice + 31 páginas de projectos
• Publicações — espelho indexado da fonte oficial (sem página por publicação)
• Índice + 1 página de notícias
• Índice de eventos & seminários + 4 eventos
• Educação (6 programas), pólos, contacto, newsletter
• Colaborar (parcerias) e Careers (vagas)
• Índice de blog + 20 artigos
• Loja + 9 produtos + carrinho
• Conta de utilizador (autenticação simulada)
• Auditoria SEO e este relatório (PT/EN)

Total: 123 rotas HTML estáticas geradas, todas testadas com retorno HTTP 200 e zero erros de consola.

6.1. Tokens

O sistema é totalmente token-based, exposto como CSS custom properties em static/assets/liacc.css. Não há pré-processador nem toolchain: os tokens são consumidos directamente pelo CSS, pelo que não existem divergências entre origem e produção.

6.2. Tipografia

6.3. Logótipo e favicon

Na ausência do mark oficial do LIACC, foi desenhado um logótipo tipográfico de transição: um L em negativo branco sobre fundo azul-noite, acompanhado de um nó verde-teal ligado por um filete fino. O L identifica a sigla; o nó representa a dimensão AI / computação. Ocupa os mesmos 36×36 do favicon, escala sem perda e é substituível sem impacto sobre o restante sistema.

6.4. Componentes

O inventário de componentes cobre cabeçalho e rodapé, hero, barra de estatísticas, secções tipadas, cartões de diferentes densidades (área, linha temática, projecto, pessoa, notícia, produto, blog post), badges, botões (primário, acento, contorno, fantasma, específicos de dark mode), avatares, breadcrumbs, cabeçalhos de página (claro e escuro), padrão content + sidebar, barra de filtros, linha de publicação, call-to-action de produto, tabela de carrinho e painel de acessibilidade.

Cada componente está tokenizado: a alteração de um token propaga-se consistentemente. Esta consistência foi verificada nas páginas novas (blog, account, newsletter, SEO, relatório) — todas reutilizam as mesmas classes e padrões, sem estilos ad-hoc.

6.5. Placeholders visuais

Todas as imagens do site são SVG nativos desenhados para o efeito: 9 ilustrações de produto para a loja (uma por SKU), seis capas temáticas para o blog (Research, Applied, Opinion, Tutorial, Lab notes, Events), sete placeholders temáticos partilhados entre projectos e notícias (Saúde, Cidades Inteligentes, Indústria, Administração Pública, Infraestruturas, Entretenimento e um geral). Esta aproximação garante peso reduzido (aprox. 1,5 KB por ilustração), independência de resolução e identidade visual consistente até à substituição por fotografia real.

6.6. Acessibilidade e modo escuro

O sistema incorpora um painel de acessibilidade fixo no header, com comutação entre tema claro e escuro (com detecção de prefers-color-scheme) e quatro escalas de tamanho de tipo. As preferências são persistidas em localStorage e aplicadas antes do primeiro paint para evitar flash of unstyled content. O sistema cumpre WCAG AA em contraste, possui skip-link, aria-current na navegação activa, landmarks semânticos e respeita prefers-reduced-motion.

7.1. Planeamento original (Notion)

O hub Notion do grupo estabeleceu seis sprints de duas semanas, somando o ciclo completo entre análise e launch. Cada sprint teve Sprint Goal, Definition of Done e epics afectos.

7.2. Execução real

A execução seguiu fluxo Kanban contínuo, absorvendo todos os objectivos dos seis sprints em ciclos mais curtos. O ritmo foi determinado por dependências entre epics, e não por janelas calendarizadas.

7.3. Entregáveis concretos

• Sistema de design tokenizado, documentado e verificado em modo claro e escuro.
• Modelo de conteúdo com cross-linking completo entre seis tipos de entidades.
• 123 rotas HTML geradas estaticamente, todas testadas com retorno HTTP 200.
• Blog com 20 artigos originais em temas contemporâneos de IA.
• Loja com 9 produtos, carrinho persistente e página de checkout em modo demonstração.
• Directório de 195 membros (11 com perfil curado), com ligação cruzada a projectos, áreas e linhas temáticas.
• Área de utilizador com autenticação simulada, edição de perfil, lista de leitura, autores seguidos e preferências de newsletter.
• Auditoria SEO com scorecard, práticas implementadas e recomendações priorizadas.
• Estratégia de marketing funnel com seis estágios, activações por cohort e stack sugerida.
• Suporte bilingue (PT-PT / EN) nas páginas principais, com comutador no header.

Se as componentes WordPress e E-Goi forem consideradas estritamente obrigatórias pela grelha de avaliação, o trabalho entregue pode ser migrado sem refazer a sua arquitectura. O sistema foi deliberadamente concebido para ser portável.

9.1. Plano de migração para WordPress

1. Instalação com tema GeneratePress e construtor Gutenberg + GenerateBlocks (conforme decisões técnicas pré-aprovadas no Notion, página Documentation).
2. Registo de Custom Post Types um-a-um a partir do modelo actual: person, project, publication, unit, news, event, blog_post, product (e, futuramente, dataset).
3. Taxonomias partilhadas — research_area e thematic_line modeladas como taxonomias custom (não CPTs), classificando pessoas, projectos, publicações e eventos, com mapeamento directo para arquivos WP e menus.
4. ACF Pro para os campos relacionais (espelhamento directo das relações de cross-linking).
5. Importação de conteúdo a partir dos dicionários Python existentes — um script único de json → WP REST API.
6. Reaplicação do sistema de design através de um child-theme que importa static/assets/liacc.css sem alterações.
7. WooCommerce para a loja: 9 produtos simples com os mesmos SVG como imagem de destaque; variantes mapeadas em atributos.
8. The Events Calendar para a secção Events & Seminars (seminários, provas, workshops, open days).
9. Polylang (ou WPML) para o bilingue PT/EN com URLs separados e hreflang, elevando o toggle client-side actual a uma estratégia i18n nativa de WordPress.
10. Rank Math para SEO + schema.org.
11. Menus padronizados — o menu primário de seis itens replica-se directamente em Appearance → Menus, com nesting nativo para os mega-menus.
12. Migração de URLs com redireccionamentos 301 a partir do MVP actual (o MVP em produção funciona como staging de conteúdo).

9.2. Plano de integração com E-Goi

1. Landing page (para Rise Up ou MSc Transformação Digital, se reutilizarmos a brief original) criada directamente em E-Goi.
2. Campanha de Email Marketing com automação welcome → nurture → conversion.
3. Campanha SMS — lembrete de evento / open day.
4. Campanha Voice — seguimento manual a leads qualificados.
5. Webhook entre o site e E-Goi: cada sign-up em /newsletter/ ou em /account/ propaga preferências de tópicos como campos personalizados para segmentação.

Estimativa de esforço adicional: 2–3 dias de trabalho focado, aproveitando integralmente o conteúdo, a arquitectura e o sistema de design já produzidos.

A componente individual é uma proposta estratégica de transformação digital que parte do MVP colectivo aqui documentado e o projecta no futuro. Apresentada em Maio de 2026 no âmbito do Mestrado em Transformação Digital (UMaia), tem por título LIACC Companion — um sistema integrado de descoberta, retenção e conversação para o portal institucional. As secções seguintes condensam essa apresentação e articulam-na com os entregáveis de marketing já produzidos.

10.1. Tese de partida

Qual é o objectivo primário de um site académico? Construir e sinalizar capital reputacional científico. Não é divulgar publicações — isso é mecanismo; não é vender mestrados — isso é consequência; não é atrair indústria — isso é derivado. O objectivo primário é o activo que se traduz em três retornos concretos:

• Captação de financiamento — FCT, Horizon Europe, ERC, contratos com indústria.
• Atracção de talento — doutorandos com bolsa, pós-docs internacionais, concursos.
• Parcerias estratégicas — B2B, B2G, redes internacionais, transferência de tecnologia.

10.2. Diagnóstico do site actual

Um site informacional num mundo que pede um site relacional. Quatro segmentos com intenções distintas — investigador, estudante, indústria, comunidade internacional — recebem a mesma narrativa institucional indiferenciada.

• Navegação plana — oito secções no primeiro nível, sem hierarquia visível e com comportamento móvel deficitário.
• Acrónimos sem chave — PRODEI, PDCC, MAP-I, LASI usados sem contextualização para o leitor externo.
• Densidade textual — conteúdo acumulado por adição, nunca por curadoria; desencoraja a leitura.
• Tecido relacional ausente — sem aquisição, sem retenção, sem conversão; tráfego restrito a quem já conhece a marca.

10.3. Proposta — LIACC Companion

Um agente conversacional persistente, articulado por uma memória comum. Uma plataforma, três modos, uma engrenagem:

• Modo Descoberta — «Recomendado para si»: cruza marcações de interesse, histórico e produção recente; aparece à entrada.
• Modo Digestão — TL;DR de ~30 s e cross-links contextuais em cada página de conteúdo.
• Modo Conversação — conversação livre com RAG sobre o corpus, citando as páginas-fonte.

A memória persistente é o activo central: sem ela, três funcionalidades soltas; com ela, um companheiro que aprende.

10.4. Aquisição e conversão — a estratégia de marketing

Blog SEO atrai. Cadastro retém. Cada artigo é uma porta de entrada construída para uma pergunta concreta («Como aplicar RL em mobilidade urbana?», «PRODEI vs MAP-I?»), com cadência de dois posts por semana, alinhada às linhas temáticas e optimizada para Google e para LLMs. O cadastro é apresentado como ganho de utilidade, nunca como muro. Quatro alavancas:

1. Cadastro como utilidade — salvar para depois, alertas, memória do Companion entre sessões.
2. Conteúdo editorial premium — whitepapers, industry reports, guias; gating eticamente neutro.
3. Newsletter por linha temática — Saúde, Cidades, Indústria; lead magnet de altíssima qualificação.
4. Acesso prioritário a eventos — open days, workshops, seminários, anúncios de bolsas.

Esta camada concretiza directamente os entregáveis de marketing produzidos no projecto colectivo: a estratégia de marketing (funil de audiência e activações por cohort) e a jornada de leads (drip de 7 emails despoletado pela subscrição, desenhado para E-Goi). Os formulários de manifestação de interesse em Collaborate, Careers e na página de Educação são as portas de entrada deste funil.

10.5. Roadmap em cinco etapas (18 semanas)

Cinco etapas sequenciais — cada uma destrava a próxima.

A Fase 01 corresponde, em larga medida, ao MVP colectivo aqui documentado (V0.1): taxonomia, schema.org, canonical, sitemap, padrões de página, área de conta e blog já entregues. É o chão sobre o qual a RAG e o Companion assentam — sem ele, o blog não tem template, a RAG não tem corpus indexável e o Companion não tem onde se firmar.

10.6. Métricas-alvo (pós-implementação)

10.7. Limitações e mitigação

Diagnóstico honesto: cada risco com a mitigação operacional correspondente.

Fecho. Transformação digital não é adopção de tecnologia — é a alteração efectiva da relação entre a instituição e os seus públicos. O LIACC produz inteligência artificial diariamente; o Companion garante que se apresente à altura.

Para além do MVP navegável, o projecto produziu quatro entregáveis de consultoria autónomos. Foram retirados da navegação institucional — por serem meta-trabalho da unidade curricular, e não oferta do LIACC — e reagrupados aqui, dentro do relatório, onde pertencem.

O trabalho foi executado individualmente, em stack alternativa à sugerida na brief, assumindo uma postura de consultoria técnica. A entrega consiste num MVP funcional, auditável e publicável imediatamente, que cumpre o objectivo de negócio — site institucional LIACC com arquitectura de informação sólida, sistema de design coerente, loja operacional em modo demonstração, blog activo, área de utilizador, estratégia de marketing funnel, conformidade SEO e acessibilidade — e é compatível com migração para WordPress + E-Goi caso a grelha o exija.

A componente individual (§10 — LIACC Companion) projecta este MVP num sistema de descoberta, retenção e conversação, fechando o arco entre o que foi entregue (a base, ou Fase 1) e a visão estratégica de transformação digital (Fases 2 a 5). A estratégia de marketing e a jornada de leads para E-Goi deixam de ser anexos: passam a ser a camada de aquisição e conversão que alimenta essa visão.

Agradece-se aos docentes João Almeida, Carlos Alves e Samuel Anjos a disponibilidade para avaliação.

Documento navegável. Uma versão em inglês está disponível em /report/en/. A fonte canónica de publicações do LIACC encontra-se em liacc.fe.up.pt/publications.