At my company we are redesiging our e-commerce website. HTML and CSS is re-written from the ground up to make the website responsive / mobile friendly.
Since it concerns one of our biggest websites which is responsible for generating of over 80% of our revenue it is very important that nothing goes "wrong".
Our application is running on a LAMP stack.
What are the best practices for testing a major redesign?
Some issues i am thinking of:
When a/b testing a whole design (if possible) i guess you definitaly
dont want Google to come by and index youre new design (since its
still in test phase). How to handle this?
Should you redirect a percentage of the users to a new url (or
perhaps subdomain)? Or is it better to serve the new content from the
existing indexed urls based on session?
How to compare statistics from a Google Analytics point of view?
How to hint Google about a new design? Should i e.g.
create a new UA code?
Solution might be to set a cookie only for customers who enter the website via the homepage. Doing so, you're excluding adwords traffic and returning visitors, who might be expecting an other webdesign, serve them the original website and leave their experience untouched.
Start the test with home traffic only, set cookie and redirect a percentage to a subdomain. Measure conversion rate by a dimension in Google analytics, within same analytics account. Set a 'disallow subdomain' in your robots.txt to exclude the subdomain from crawling by SE's.
Marc, You’re mixing a few different concerns here:
Instrumentation. If you changes can be expressed via HTML/CSS/JavaScript only, i.e. optimizational in nature, you may be able to instrument using tols like VWO or Optimizely. If there are server side changes too, then a tool like Sitespect (any server stack) or Variant (Java only) might be in order. The advantange of using a commecial product is that they provide a number of important features out of the box, e.g. collecting experiment data, experience stability (returning user sees the same experience), etc. You may be able to instrument on your own, but unless you’re looking at a handful of pages, that typically is hard, particularly if you want to do it outside of the app, via the DevOps mechanisms.
SEO. If you get your instrumentation right, this shouldn’t be an issue. Public URIs should not differ for the control and variant of the same resource.
Traffic routing. Another reason to consider a commercial tool. They factor that out of your app and let you set percentages. Some tools, like Variant, will allow you to write custom targeters, e.g. “value” users always see control.
Related
I'm trying to reduce the size of my website, but to do that I need a reliable tool to measure the size of my pages.
I used to use Google Lighthouse, in the performance audits it reports the size, but it's not precise, and it's inconsistent with the network tab
I tried several combinations of curl, but I can't make it crawl website correctly
I tried several combinations of wget, but it couldn't handle correctly the gzip or brotli encoding
I came to the conclusion that wget or curl are not the right tools, because they don't evaluate JS, so they can't do conditional loading of assets
I'm trying now with puppetter.js and phanotm.js, but I still haven't managed to do it
Does anyone have a good solution for this?
How to Measure Size
Web browsers make a lot of decisions about what to download based on their particular context (for example, what compression algorithms it supports). It's difficult to replicate those conditions in an external tool, such as curl. So you'll want to use a tool that thinks like a browser (or is a browser).
The server can also choose to send different content based on visitor information (user agent, whether they're logged in, geolocation, etc.) or even completely arbitrary conditions (like a randomized image). So you'll want to look at more than one sample, preferably from many user agents and locations.
Most tools don't provide that kind of power.
The closest thing I can suggest is WebPageTest. It uses an actual web browser to visit your site and reports an analysis of that visit, including total page weight (even broken down by different page events). WebPageTest can be used as an API and even run locally. Output is available as JSON, so you can parse and do custom reporting with CLI apps.
How to Speed Up a Website
The technical question of "weighing" a website aside, there's a broader problem you're trying to tackle: how to speed up your website. There is a lot of information available for performance optimization.
Specifically, there's a lot of discussion about what metrics should be considered when evaluating a page's performance, how much weight should be given each metric, and how to use that information to prioritize optimizations.
When considering page weight, I would highly recommend breaking it down by how many bytes are necessary to accomplish certain tasks. Google recommends thinking about resources in terms of the critical rendering path - the HTML, blocking JS, and non-deferred CSS necessary to construct a web page.
You may have a 1MB page where render-critical assets only make up 10KB of the page - that's a very fast site. Or you may have a 1MB page where 500KB are required for an initial render - not so fast. WebPageTest helps break down those weights by event for you.
I wish I could give more technical detail about using WebPageTest with CLI tools. It's something I plan to explore soon. But for now, hopefully this will give you a good start.
Have you tried PageSpeed Insights ?
Analyze you website and read on optimization guidelines.
In my company we develop internal products and usually this products must be integrated (typical scenario). Our solution is always use SOA web services for this kind of task.
This is a solution that forces different products to develop same UI interfaces, and the responsibility of this interfaces or process is sometimes not clear between our teams.
I want to propose an alternative solution, I think that sometimes each product publish SOA web services but in addition publish web-pages, that other products can call to reuse.
for propose it in the work, I want document my-self because I suppose that this kind of integration is already invented, and have a name, examples, tools, best-practices...
any orientation?
To me it looks like a mistake to share entire UIs across applications. This will violate the separation of concerns principle, and will couple applications to each other. Also, you will end up losing autonomy because an external application will control how your UI looks. You will have all kinds of issues, related to the inter-dependencies between applications. These are the first that come to mind:
I assume the information is not public. If so, you'll need single sign-on between applications. In order to implement some level of security (at the very least authentication) you'll need to integrate all your applications within a single sign on-solution or invent some kind of convention for passing tokens between applications.
It will be very hard to implement even primitive authorization if needed, because naturally roles in different systems vary, especially across business domains.
If you have to filter any data by some property, it will have to be transferred in the request to the central application that holds the GUI prior to displaying. The whole processing of data and preparation for visualization will then be responsibility of this central UI system. This will lead to insane amount of caller-specific rules for each caller that uses the central UI.
Any complex UI required by applications will still have to be implemented locally, so you only solve the issue partially.
Here is what I would do in your case if I really must implement central UI, although I advice strongly against it and would prefer sticking to SOA with some kind of middle ware (ESB or even more primitive EAI software that limits point-to-point integration). You can decide for yourself if it is worth the time and effort:
I would only offer a very limited version of UI that is 100% based on the service layer that already exists and is generated automatically. This means - if you change the service the UI accommodates the new data and displays it automatically. If an application needs complex visualization it must still use the Service layer to retrieve data and implement custom UI locally. In genera, it will be better if UI and visualization are controlled by each application separately. This is much more agile and future-proof.
Hope this helps!
I'm not a Web Developer, and I don't know a lot about the web application frameworks out there.
Recently, however, I got into Wt. It's a web framework written in C++ (that's why I got into it), but what impressed me the most is the idea it's based on.
Its API is different from any web framework I ever heard of (CppCMS, Yii, Django, Pylons, Zope, Drupals, Java Servlets, Struts ...): a new Application object gets created for any user session, and it stays alive until the session expires (only at this point the Application object gets destroied). This Application object works like a desktop window: you put Widgets in it (widgets like forms, links, labels ...); when the user clicks on a link (when the HTTP server receives a new GET/POST request) a function gets called on the object tight to the user session (in a nice Signal/Slot way), which can remove/add/change the widgets, thus changing the page the user will see.
As I said, I'm not very skilled with web frameworks, I develop almost only desktop applications; maybe for this reason I think this paradigm behind Wt is great.
I'd like to know what are the pros and cons of this framework API in respect to the other ones, and if there are other frameworks (also in other languages) based on the same concepts.
Wt is a great framework for its intended range of applications.
Wt is great for :
web apps tightly coupled to a session, i.e.
made to be accessed only by users that are logged in (except the landing page)
display a lot of user-dependent content (so not for a wiki)
relying heavily on state
web apps that need to have a lot of controls/buttons and user input.
For exemple, I plan to write a browser MMORPG. Pages will all be having a state tied to a user, and there will be a lot of buttons. Wt is perfect for that. I used to be a Ruby on Rails developper, and switching to Wt for this kind of app was a great moment. It's increadibly cumbersome to design forms with traditional frameworks that try to enforce pure REST.
Wt would also be perfect for a control interface on some process. For example, an interface allowing your customers to configure their adword campain, etc.
Of course, using Wt is not perfect regarding control and separation, but it allows extremely fast development when you need only the "classic" features (buttons, editors, etc.)
So as a rule of thumb, if you are trying to put a desktop application on the web (which is a great idea, removing the need to deploy and update on your customers' machines), Wt is a good candidate.
Also, if you are interfacing with an existing C++ codebase, Wt has an advantage.
I think this is generally bad idea.
Web application is very different from GUI one and there are many reasons:
99% of the web is about the content rather then about iteration.
You go to web to get or share content rather then to do some real time interaction
like drawing a picture, working with spreadsheet or anything else.
Web is content driven rather then "event driven" interactive application.
This has strong impact on how do you create most of web - you bring information
to user rather then interact with him.
The server and client programming is very different
There are some web GUI applications like e-Mail, Chats clients but to perform well
they require very good separation between the client side written
in high quality Java Script and the high quality server side backend that is used
over AJAX for content retrieval.
Hiding this separation like Wt does or (other known frameworks) lead to crappy
software and generally brings more problems then solutions in long run.
Because it should be very clear separation between server side and client side jobs
as some require real time response and some don't.
When you try to solve all this in one wait for problems. Note, there are client-server
solutions for GUI (see X-Server as example) but unlike web they designed for this
and rather work more like IPC rather then client-server solitions.
The web is stateless most of the time.
Or to be more correct the state usually keeps quite small amount of data.
Creation of instant session object is nice idea until you need to...
Scale up save state in long terms then this model becomes not so good, of course
this not "forced" model by Wt but it is general concept that fits certain concept
and some does not.
Bottom Line
If you want to design good GUI like web application. Start learning JavaScript and use good GUI JavaScript frameworks that fit well to GUI even driven design. Then combine them with some server side API using some interaction RPC model like Json-RPC, XML-RPC and other
AJAX tools.
This is the way to do things right for highly interactive applications.
If your application is more content oriented then most of server side web
frameworks do great job - concentrate on server side with its great tools suitable
for the job.
All in one solution? It just does not work...
Disclosure: I'm developer of CppCMS and I think Wt just goes in wrong way.
ASP.NET is similar; it has the same goal to make web development look like desktop application development.
For software used in a call centre guiding agents through a set script they must follow while on telephone calls, with the script branching dependant on answers to questions given - My system uses a MS Access / VBA front end (isnt web based due to speed, phone integration), 'call scripting' is coded in VBA when needed, but what if i want move to a more complete solution?
Is hosting a HTML/ms webbrowser control the obvious platform to build call scripting on?
A manager view will also be needed allowing managers to create scripts, divide it into parts, specify routing rules that determines the path through the script, link input boxes (ie question answers) back to database fields, specify validation rules as well.
Thinking about the complexities of building the manager view that translates the intended script into HTML/Javascript, is creating my own simple doc description language with tags for just the features i need and a 'rendering engine' in VBA a solution you might consider for this?
Ive thought about creating scripts out of standard Access controls, using relational table structure to hold the info of what controls relate to what parts of scripts, validation, routing options etc but i think due to Access' lack of runtime control creation this will be more painful than a rendering engine that takes a script written in my own doc desc language and displaying it.
What suggestions have you for the implementation of this?
The actual user interface requirements of the user-facing part of your system seem to be pretty minimal (ask question, get answer, branch to "next" question). I don't think there's any "obvious" platform to use. As always, a browser based system makes it easier for geographically scattered users to use a centralized system but will probably cost more in terms of development.
The manager-facing part of the application is more interesting and for that I'd probably suggest a desktop application rather than a browser based one. I can see this relying on a lot of drag-and-drop and line-drawing type functionality and that kind of stuff is still easier to do on the desktop, at least in my opinion.
Assuming that you can clearly define the kinds of question routing and decision points that a script has, and these decisions are relatively simple, I probably would write your own specification for how a survey is represented. The manager-facing application would create, edit, and save a specification and the user-facing application would read and step through one.
Given my personal skill set, I'd probably write both applications in Delphi, develop an XML format to represent the survey specification, and consider either XML or relational storage for the back end depending on what you actually wind up doing with the data.
I'm inclined to agree that a web interface is optimal for something like this, however WPF is a great alternative as well with many of the advantages of a web interface along with the power of a desktop application. Both web and WPF would give you considerable amount of control over how the application looks and feels, leveraged with all the power of the .NET framework. One drawback of a web app is that you have less ability to interact with the phone system directly, but I'm sure that's a problem that can be mitigated fairly easily with some AJAX. A big plus for the web platform option is that you'll have access to tons of client-side interactivity libraries like jQuery, which will allow you to polish the application with greater ease; with WPF you would likely find yourself paying for a lot of the fancy UI controls.
There is quite a few survey and question (test creating) systems built in access. I don’t see any real issues in using access as opposed to whatever system.
The advantage of HTML or text based systems is they tend to support a more dynamic type of screens.
On the other hand, for questions and display of text, in access a great trick is to place a sub-form control on a form, and then at runtime simply “set” what form is to be displayed in that sub-form (the source object properity). In fact, in access 2010, the nav control does exactly that and it displays forms as a sub-form.
Also for access 2010 we can create web based applications. In this video you can see that the half way mark, I switch to running the application in a standard browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
However, the above means little here, as I not sure what you mean by some type of rendering engine. Each question + response is simply going to be some text on a screen, and thus you can simply display/change that text by changing the underlying reocrdset.
And, if you want nice formatted text with different fonts etc, well access 2007 now has support for rich text (markup text). So I don’t think you really need dynamic screen creating. Between changing the record source to display whatever text you want, and that of being able to display different forms (templates) on the fly by changing the sub-forms “source object”, you can well change part of your screen to display different text boxes with very little code.
On the other hand, if you have all of the .net tools and want to create a browser based application then you are free to do so. I suppose you could also wait for access 2010 to create a browser application.
If you willing to keep this simple, then access is a great choice. If you need a browser based application, then I don't access is the choice here.
I want to design a website but I don't know from where to start.
Is there a beginners' guide to start with?
How much dedication do you hope to provide? If you merely want to design a single website, quickly and dirty, there's a plethora of open source web templates available online, with clean and basic HTML/XHTML design strategies that you could modify, and provide content for.
Such as this and that.
Alternatively, if you would like to design your own websites from scratch and have full technical knowledge in the field (the proper way). Pick up a book or two on HTML/XHTML/XML, with documentation on content management systems, php, etc.
You'd soon find that in the beginning your development would be gradual and at best, slow. If you put in sufficient effort, you would find that you get to the point where you can quickly design sites confidently, which best illuminate your content.
You should be familiar with this and this
Try this Web Design from Scratch
I understand by website you mean some kind of web-app. And by design you mean, not just the page design but the design of the web-app. First, you have to understand the anatomy of a web-app. The major components are:
Database is used to store user and application data for long term. A database provides query functionality (SQL), backup on one installation and restore on another, triggers when a data entry changes, and constraints that must be satisfied by the data tables.
Web Server, also called Http Server hosts the web application.
Web Browser such as Internet Explorer or Firefox.
When a user types a URL into the web browser, the web server forwards the URL to the corresponding web application. The web application performs the needed tasks (which may involve reading or writing into the database) and returns a new html page to the user via www.
Some components of the web application are:
Database access objects are representations of objects that encapsulate interaction with database tables.
Business Logic is the main logic of the application. Here we implement the search functionality using Lucene library, for example.
Action Handler handles a http request received from the user, for example when she types a URL or when she clicks on the "submit" button. These are Http GET and POST requests. The Action Handler uses the business logic to drive the actions.
Data view on the web brower is constructed using some template library (which usually produces javascript user interface code for the web browser). For interactivity one may use Ajax techniques.
Almost all web-apps separate the model, view and controller of a web application. The view deals with the display, the model deals with data and the controller deals with control/functioning. See http://www.uidesign.net/Articles/Papers/UsingMVCPatterninWebInter.html.
Several frameworks implement MVC. The most easy ones to get started are Ruby on Rails and Django (over which an open source social network called Pinax too is written). There are much more comprehensive frameworks and libraries in java too (for a single web appl you may need to join several of these libraries), such as spring, webwork, tapestry, lucene (for search), sitemesh (for page decoration). Many java web apps run on tomcat web server and with mysql database.
I started with http://w3schools.com. Make sure you're using Firefox and the Firebug addon. Get your hands dirty then get familiar with the web design community.
I have CSS Mastery by Andy Budd on my desk and it's a good, readable, short, yet deep guide to CSS.
Don't Make me think has also become my mantra of web design.
Overall, you're going to produce a lot of crap--as I have--before you get good. If you have someone to look over what you're doing that'll be the best help. Personal drive will matter the most in the long run though, so stick with it and keep learning.
Liz Castro has a good book too.