Ecommerce-Store Magento News

Nell’ultimo anno, sono stato attivamente coinvolto nello sviluppo dei negozi online su piattaforma Magento ECOMMERCE. Tutti quelli coinvolti nello sviluppo di Magento possono dire che Magento utilizza in modo approfondito l’approccio OOP. Sebbene non tutti siano d’accordo, mi piace il modo in cui la piattaforma è stata architettata nella backend. I layout e file di configurazione ti permettono di avere a disposizione una grande potenza senza mai scrivere una sola riga di codice PHP. Non è perfetto, ma questo è. Credo che la maggior parte di voi ha sentito dire il cliche: “Da una grande potenza deriva una grande responsabilità”. Discutiamo di questo a proposito di Magento.

c’è un messaggio semplice e chiaro che vorrei gridare agli attuali e ai futuri proprietari dei negozi online di Magento: “Sii serio, concentrati su quello che ti interessa di più!”

Cosa ho avuto (e ancora ho) in mente con un affermazione del genere? Diversamene da WordPress e Drupal (nessuna offesa, li uso e li rispetto), non tutti sono capaci di sviluppare moduli (estensioni) di qualità per Magento.
La stessa piattaforma richiede ai suoi sviluppatori un conoscenza decente che include PHP, OOP e altri oggetti correlati a vari concetti. Come spiegato in uno dei miei articoli precedenti, Osservatori e “overrides” sono tra i miei concetti (approcci) preferiti, per quanto riguarda lo sviluppo del modulo di Magento.

Uno dei progetti a cui sono stato assegnato qualche settimana fa, aveva una grande quantità di prodotti, 46 268 per essere precisi. La maggior parte di essi sono prodotti semplici con “Visibility”:”Nowhere” e vengono usati esclusivamente come prodotti Associati con alcuni prodotti Configurabili. I prodotti Configurabili sono per la maggior parte mostrati all’utene nel frontend. Tutto sommato, nel sistema è presente una manciata di prodotti Configurabili, ognuno dei quali contiene qualche migliaia di prodotti Associati.

Qui ci sono due questioni. La prima e la più fastidiosa l’ho incontrata nella configurazione “WTF” e riguarda la performance. Collasso completo di ogni tempo di esecuzione ragionevole. Il caricamento di una pagina che contiene questo genere di prodotto Configurabile, impiega dai 3 ai 9 minuti, sia sulla fronted che sulla backend. Mi riferisco a circa 3-9 minuti su una macchina locale con i settaggi al massimo sia per PHP che per SQL. La seconda questione è l’ovvio fraintendimento dei tipi di prodotti Magento e come usarli.

Ho già preso parte ad un progetto di Magento con approssimativamente lo stesso numero totale di prodotti nel sistema. Il numero di prodotti non impone, da solo, il notevole calo di performance se i prodotti sono usati in “maniera intelligente”. Con “maniera intelligente”, penso a condizioni dove si è persa  una somma di prodotti Semplici indipendente. Magento può occuparsi di questo abbastanza bene. Ad ogni modo, avendo una grande somma di relazioni come queste Configurable Products > Associated Product, il tuo negozio può essere ucciso con un “usabilità pari a zero”.

Qui è dove ho tracciato la riga sulla pezzo degli sviluppatori. Se sei abbastanza fortunato da ottenere un lavoro su un nuovo progetto relativo a Magento partendo da zero, sei obbligato a riconoscere questi tipo di problemi e a riconoscerli in tempo. Cambiare approccio per strada su come i prodotti devono essere presentati nel sistema e così via. Non è accettabile creare migliaia di prodotto Associati solo per agire sul prezzo finale dei prodotti Configurabili. Se devi usare una soluzione come questa, prova a sviluppare un modulo personalizzato per lavorare sulla questione, non ad andarci intorno. In casi come questi, il crollo delle performance è garantito. Quindi, se il cliente viene con un idea tipo “Ho tantissimi prodotti che ricadono nella categoria dei prodotti Configurabili che possono usare questo e che, in quanto prodotti Associati, possono rimanere dinamici in questa e in quella selezione…” hai bisogno di fermarti, pensare due volte a come si riperquoterà sull’intero negozio e poi proporre la soluzione. Non devi andare alla cieca con i suggerimenti dei clienti (proprietari). La loro prima volontà è ottenere uno store che funzioni e che venda con il minor budget possibile.

Adesso diamo un’occhiata ai proprietari (clienti). Ho notato come molti proprietari abbiano richieste “speciali” per i negozi Magento. Molti di loro hanno prodotti che ricadono sotto la categoria “Grouped”, “Bundled” e “Configurable products”. In realtà questo è magnifico, visto che tutti loro vengono fuori nel box di Magento. Quello che non è così bello è che le loro volontà a volte possono essere un pò “irragionevoli”. Diamo un’occhiata alla funzionalità “cambiare colore”, che molte persone richiedono sia implementata. Questo tipo di funzionalità è stata fatta prevalentemente con JavaScript, dove si nasconde il box di selezione che Magento normalmente mostrerebbe sotto opzioni prodotto, e così via.

Sicuramente ha un aspetto fantastico, ma la vera domanda è “Quanto migliorerà la tua vendita?” Ho capito che l’usabilità può essere più importante della funzionalità. Ormai, ci sono sempre dei moduli per cambiare il colore che possono essere acquistati. Ad ogni modo, la maggior parte dei moduli di Magento, richiede del lavoro extra, affinche siano implementati correttamente per andar bene alle esigenze dei proprietari. A causa della complessità della piattaforma Magento, a volte anche i più piccoli cambiamenti richiedono molto tempo e grandi sforzi da parte dello sviluppatore. Sarebbe fantastico se tutto funzionasse dopo l’aggiornamento dei Magento Store ad una nuova versione. Tutto ciò comporta che l’intero processo di sviluppo si concentri sulla “piccola cosa”. Dico io: perchè non modellare il tema con la pagina di setup predefinita? Perchè cambiare l’aspetto della pagina del prodotto? Perchè non lasciarla standard, soltanto completamente modellata per accordarla al proprio design? Questo tipo di approccio sarebbe più sicuro sia per futuri aggiornamenti sia per i tempi che si accorciano il più possibile.

Quello che sto cercando di dire è che Magento è estremamente ricco di caratteristiche. Il tempo per lo sviluppo non è gratis e la mia opinione è che bisognerebbe concentrarsi sulla costruzione di nuove e fresche caratteristiche, oppure su altre parti del sistema come la Promozione, le regole di prezzo del Catalogo, Le regole di prezzo del Carrello, i gruppi Personalizzati. Quest’ultimo sembra essere relativamente ignorato nella grande immagine.

Aggiungere funzionalità come il “cambio di colore” potrebbe essere lasciata come ultima fase di sviluppo, quella da fare dopo che il sito viene messo online, quella da fare quando si è sicuri che il proprio negozio funziona nella maniera in cui dovrebbe, è stabile, con un certo stile, ottimizzato per le migliori performance, e discretamente strutturato in modo che sia relativamente sicuro sugli aggiornamenti. Solo allora puoi cominciare ad aggiungere moduli, modifiche simpatiche per l’usabilità e così via.

Fonte: Inchoo.net