Quoi il est très bien Opera
Quoi il est très bien Opera
Je dis pas le contraire, juste qu'il y'a pas beaucoup de monde qui l'utilise...
Vous auriez des exemples de sites web qui proposent des champs de recherche en AJAX complexes mais sympa ?
En fait je voudrais faire un champs qui permette de rechercher plusieurs trucs différents.
Pour donner un exemple, c'est comme si sur leboncoin vous aviez un seul formulaire ou un seul champs de recherche qui permette de rechercher à la fois un vendeur, une annonce, une ville, etc. tout en donnant la possibilité de choisir une catégorie ou une gamme de prix dans le cas d'une annonce, de choisir une distance de recherche autour d'une ville, etc.
Ca ferait un formulaire assez complexe et donc pas très clair.
Du coup je sais pas s'il y a des méthodes pour rendre ça sympatique.
Peut être en masquant certains champs de formulaire jusqu'à ce que la recherche se précise, ou bien en mettant une liste de commandes au fur et à mesure où on tape. Bref, je sais pas trop.
Rust fanboy
Le plus efficace amha ce serait d'avoir un select qui te permet de choisir ce que tu recherche, puis ton input text qui va chercher selon ta sélection.
Sinon tu peut faire comme duckduckgo avec les !bang
Exterminate !
Y'a aussi https://github.com/launch dans le genre, un input qui te permet d'avoir des tonnes de trucs (recherche, commandes, etc.).
Le plus important surtout c'est d'avoir du feedback quand l'utilisateur commence à remplir et une aide qui donne la liste des options possibles, pour avoir une courbe d'apprentissage pas trop raide.
Ouaip j'ai déjà cherché des idées en m'inspirant de ce truc.
Pour l'instant ce que je pense faire c'est :
- quand l'utilisateur commence à taper un truc, une recherche côté client est faite et s'affiche une liste de toutes les possiblités de recherche offertes à l'utilisateur (par exemple si je tape le nom d'un X, s'affichent : aller à X, rechercher d'autres X près de X, rechercher des Y appartenant à X, etc.)
- si l'utilisateur cherche un X on affiche les champs de formulaire qui permettent d'affiner la recherche d'un X, s'il cherche un Y on affiche les champs pour affiner la recherche d'un Y, etc.
- les résultats s'affichent sous forme de petites vignettes AJAX à droite du formulaire
Après le "problème" c'est qu'il faut que je charge côté client une liste de tous les X, Y, Z, etc.
Je ne pense pas qu'une liste de commandes séparée soit nécessaire. Déjà parce que ce sera pour des noobs du net (pas comme github ou duckduckgo), et en plus je pense que si je mets un placeholder "X, Y, Z, W, R, ..." à l'intérieur de l'input, ils commenceront déjà à taper des trucs dedans et verront par eux mêmes.
Vu que c'est le gros truc qu'on mettra en page d'accueil je pense que ça vaut le coup de passer un peu de temps là dessus.
Rust fanboy
T'as intérêt d'avoir un bon serveur SQL pour traiter tout ça rapidement.
Sinon, faudrait que tu fasses une bdd avec mots-clefs + catégorie (produit, vendeur, ...) pour fluidifier un peu tout ça et limiter tes requêtes.
Je reste vague car même si mon vrai nom est trouvable si vous fouillez bien, j'ai pas envie d'étaler mon boulot sur un forum.
En fait pour préciser un peu, ce seront notamment des villes, des événements ponctuelles et des activités (non ponctuelles, du genre club sportif).
Donc pour reformuler, si par exemple l'utilisateur tape dans le champs "Trouville", j'affiche un menu avec comme éléments "Voir la fiche de Trouville" et "Rechercher des activités/événements à proximité de Trouville" (et à ce moment-là s'affichent un slider pour choisir la distance, plus un choix de catégorie d'événements/activités), etc.
S'il tape "Tr", j'aurai comme éléments "Voir la fiche de Trouville", "Recherche à proxi. de Trouville", "Voir la fiche de Trifouilly-les-oies", "Recherche à proxi. de Trifouilly-les-oies" et "Recherche événement/activité : tr...".
Eventuellement un autre élément "Recherche activité : trekking" si je trouve du trekking dans la base de données.
Rust fanboy
Ca me semble pas mal. Maintenant, 'faut trouver une incitation pour que les gens pensent à se servir de ton mono-champ plutôt que de chercher un champ "recherche une ville" ou "recherche d'évènement"...
Le champs est le premier truc en haut de la page d'accueil (en dessous du bandeau principal), fait le tiers de la largeur de la page et 25px de haut. Je pense que ça devrait suffir.
Il faut juste que je mette un placeholder "Rerchercher Ville, Evénement, Activité, ..."
Rust fanboy
Enfin des gens qui montrent que les slider "cay de la mayrde" et ça ne rapporte rien \o/
http://conversionxl.com/dont-use-aut...gnore-the-fad/
Exterminate !
Il dit pas texto que c'est de la merde mais que c'est pas un bon moyen de vendre.
Comme toutes les conneries HTML 5/web animé en fait.
En même temps la Homepage c'est plus ce que c'était
Grand maître du lien affilié
En même temps, pour pondre un site web, rien ne vaut le fameux frontpage associé à dreamweaver.
Carousels are effective at being able to tell people in Marketing/Senior Management that their latest idea is now on the Home Page.
Exterminate !
Aujourd'hui j'ai mis en place un Sharepoint 2013 pour faire l'intranet de ma boite.
Je ne connaissais pas du tout, et bien faut dire que ça tue, design de base très sympa, des modules efficaces fournis de base, simplicité d'utilisation, etc.
Le seul gros défaut que j'ai trouvé pour le moment, c'est le serveur de brut qui doit aller avec (surtout qu'il faut compter un serveur en plus pour la bdd).
Bof, pour une grosse PME ou une GE, c'est ridicule ces coûts.
Tiens, question paradigme de programmation : vous faites de l'unit test pour tester vos sites web ?
J'aime bien l'unit testing pour les logiciels : ça rassure, ça aide à détecter les erreurs débiles.
Mais pour un site web, je suis assez réservé.
Côté serveur il faut mettre en place toute la base de données, ce qui est assez lourd à faire. Evidemment si la base de données est simple, c'est assez facile à mettre en place et à maintenir. Mais si la base de données est simple, t'as pas non plus besoin de unit testing.
Côté client je sais qu'il y a des logiciels qui permettent de faire des "captures" du site et de les comparer avec ce qu'il faudrait obtenir. Mais là aussi c'est 3 fois plus long de mettre en place les tests que d'écrire le code.
Et puis s'il faut passer 30mn pour réécrire la moitié des tests à chaque fois que tu déplaces un machin de 3px sur la droite, ça doit être assez vite pénible.
Rust fanboy
Pour le moment, je ne le fais pas. Par contre, si je devais faire un semblant d'unit testing pour les sites web, j'ferais ça avec CasperJS.
En gros, tu lui dis "Va sur la page à telle adresse, trouve tel formulaire, remplis-le avec telle et telle info, soumets et regarde si tu obtiens bien ce résultat".
Une fois que t'as ça de fait, tu balances le test et t'attends sagement qu'il te crache les résultats.
Ca a l'air sympa, mais encore une fois ça doit être lourd à écrire.
Si maintenant google décide du jour au lendemain d'afficher 9 résultats au lieu de 10, ils seraient obligés de changer leur test. Pour moi les tests c'est supposé ne jamais changer à moins de modifier en profondeur le design du programme.
Au final j'ai peur que 95 % des fois où le test fail, ben en fait c'est à cause du test et pas à cause du code.
Ce que j'envisage peut être de faire, c'est écrire une liste d'URLs ainsi qu'un petit script qui va envoyer un GET à chaque URL et vérifier si toutes renvoient un code 2xx.
C'est assez basique comme unit test, mais ça peut déjà être pas mal pour détecter si on fait une connerie lors d'une modif.
Rust fanboy
HAN Skiant il confond les tests unitaires et les tests fonctionnels !
Avec Symfony j'ai fais les 2.
Et clairement les unitaires c'est incontournables quand on commence à faire des trucs avec des calculs. Ne serait ce qu'un compteur qui s'incrémente.
Ou quand on fait un traitement de texte, vérifier que la sortie est bonne.
Bref en général si tu as un "gros" controler, y'a de bonne chance qu'un ou plusieurs tests unitaire soient utiles.
Dans ces cas ne pas hésiter à développer par les tests et à ensuite coder la méthode qui va bien.
Ça permet d'emblé d'anticiper les cas de figure tordus.
Pour maintenir la base pas de problème, y' un système de migration dans Doctrine : http://symfony.com/doc/2.0/bundles/D...dle/index.html
Et a la fin d'un test on peut effectuer un rollback sur la base pour garder le jeu de test propre.
Les tests fonctionnels c'est clairement le plus utiles mais aussi le plus chiant.
Déjà par ce que c'est long a exécuter, lourdingue à maintenir par ce que ça se base sur les éléments d'affichage.
Mais ajouter simplement un test sur chaque page pour checker si elle retourne 200 et pas 404 ou 500, c'est déjà un gros bonus.
---------- Post added at 15h53 ---------- Previous post was at 15h46 ----------
Et non c'est pas super relou a écrire
Tester (unitaire) une addition par exemple :
Tester fonctionnellement un code 200 avec symfony :Code PHP:
namespace Acme\DemoBundle\Tests\Utility;
use Acme\DemoBundle\Utility\Calculator;
class CalculatorTest extends \PHPUnit_Framework_TestCase
{
public function testAdd()
{
$calc = new Calculator();
$result = $calc->add(30, 12);
// assert that your calculator added the numbers correctly!
$this->assertEquals(42, $result);
}
}
RTFM : http://symfony.com/doc/master/book/testing.htmlCode PHP:
// src/Acme/DemoBundle/Tests/Controller/DemoControllerTest.php
namespace Acme\DemoBundle\Tests\Controller;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
class DemoControllerTest extends WebTestCase
{
public function testIndex()
{
$client = static::createClient();
$crawler = $client->request('GET', '/demo');
$this->assertEquals(
200,
$client->getResponse()->getStatusCode()
);
}
}