I have an existing website. I have pages on this website that represent products with reviews. I want to use microdata to expose the aggregate reviews on Google. My challenge is each product page is fairly complex. We spent a lot of money getting the design the way we wanted it. While our search results look good now, we're not sure how to add the aggregate review information.
I reviewed the information found here. However, that looks like we would have to change our page design. We don't want to do that. Is there a way to get the aggregate review search engine result without changing our design? Ideally, I would really like to just put something in the .
You can scope metadata to encapsulate you whole page, so even on the body tag. This way the information can be spread around your whole design and still be part of the same entity.
If your information can't be hierarchical to form the correct entity you can use the itemref attribute. To quote the standard:
Note: The itemref attribute is not part of the microdata data model. It is merely a syntactic construct to aid authors in adding annotations to pages where the data to be annotated does not follow a convenient tree structure.
Related
Good day!
I cannot find a complete description of the very items that make this concreate schema useful for business in SERP. I realy don't understand why should irganization markup schema if it provide no benefits in search result? isn't it easier to create an account in Google My Business or in some Catalog with reviews on it? In this case we can see the snippet with 'rating stars'.
For example, there are two sniipets from search result:
organization1 has Schema.org/Organization markup on its' page:
Search result snippet1
organization2 has no markup on its' site, but has it's page in catalog Yelp:
Search result snippet2
Moreover, I cannot understand how can "aggregateRating" (based on a collection of reviews or ratings, of the item) calculate this rating?
Please, can anyone explain it to me?
Check the FAQ section with regard to Schema.org in the About Section Answers related to your question are:
Q: What is the purpose of schema.org?
Schema.org is a joint effort, in the spirit of sitemaps.org, to
improve the web by creating a structured data markup schema supported
by major search engines. On-page markup helps search engines
understand the information on web pages and provide richer search
results. A shared markup vocabulary makes easier for webmasters to
decide on a markup schema and get the maximum benefit for their
efforts. Search engines want to make it easier for people to find
relevant information on the web. Markup can also enable new tools and
applications that make use of the structure.
Q: Why are Google, Bing, Yandex and Yahoo! collaborating? Aren't you competitors?
Currently, there are many standards and schemas for marking up
different types of information on web pages. As a result, it is
difficult for webmasters to decide on the most relevant and supported
markup standards to use. Creating a schema supported by all the major
search engines makes it easier for webmasters to add markup, which
makes it easier for search engines to create rich search features for
users.
There's also a video on youtube about using schema for SEO for you business.
Structured data is a standardized format of code that is added to a web page. It communicates specific information about a page to Google. This makes it easier for search engines to crawl and index your content faster. In other words, it provides the context search engines need to properly categorize your site and recommend it more accurately for relevant search queries.
Google is using this data to make their search engine more accurate by creating a knowledge graph. This graph is an interconnected map of entities that follows the relationship between different terms, facts, data, dates, and more. This allows Google to go from keyword matching to a context-rich search engine, capable of differentiating the Taj Mahal monument from the Taj Mahal casino in Atlantic City.
What it means for SEOs is that Google has given you a way to introduce your client’s brands and companies into their knowledge graph, making them real objects Google knows about and can recommend to users. Check out our structured data guide on how to implement it on your site, including the recommended format for SEO and more on schema markups and aggregateRating.
I am just starting a project and the wireframes are ready. But looking at the wireframes it seems that the primary goal was to reduce the number of pages and to include maximum functionality in to a single page.
Taking an example of an organization, the top portion of the page will show the organization details, below that at the left we have an division structure as a tree view, clicking on a division will populate the employee list on the right as a table, and when you click on an employee it will populate the employee details below.
Current wireframe looks something like this:
End user is happy as they can see the entire functionality on a single page and doesn't need to navigate to another page.
But this design reminds me the screen of some old desktop application and I feel that this page is unnecessarily complex- I want to split this in to multiple pages (at least in to three). Also, I am using MVC 4 and splitting this in to multiple pages will definitely help me to reduce the complexities during implementation.
But before arriving at any conclusion and raising any concern, I would like to know what you guys think. Some articles related to User experience are also welcome.
Here's what I think.
Whether the design above is 'right' depends on the target audience and the type of work / business process they need to carry out. There may be a strong business argument for being able to see all the information (org details, divisions, employees and employee details) on one page. It is not unusual to see a lot of information displayed in a page with a lot of interactivity - users expectations have increased because of consumer sites such as Gmail.
The users might find it frustrating if it was broken out into different pages.
To put it another way, I don't think there is a valid technical justification for making the designer change the UI above to split it into different pages.
You would be able to build the UI above in MVC as a single page web application. You will probably need to implement a lot of controller actions to support ajax calls. You're almost certainly going to end up using a lot of JQuery and you are probably also going to end up with a significant amount of JavaScript to write. Also, you'll need to make sure the designer has made good decisions around the sizing of the page. Is it going to be fixed width or dynamic for instance? You'll need to emit well structured HTML in order to achieve that solely using CSS (which I would strongly advise you do).
I am a little ashamed for asking so many questions, but I really want to learn.
In Sipke's blog a webshop is created. There is one specific question that boggles my mind when trying to do something similar.
Let me spell out the basic requirements:
User registration form and login, etc. This one is covered by the blog and it works nice.
Creating product parts and so on. This one is covered and no problem there.
Ordering by filling in an order form and making the payment. See down
Having the order page maintainable by customer. See down.
Viewing your own orders and their status. See down
Maintaining customers and orders from backend system. This one is covered by the blog and I need to do some work there yet.
As for items regarding creating orders and viewing your orders. I have followed the approach for creating records and using standard MVC controllers. But then I encountered problems:
Menu for orders page. This I had to do manually after installing the module.
The order page itself. I had to create the view including title and so on. But I can imagine a customer wanting the order page on another menu and with a different title. And maybe add even some own content to the ordering page. This I couldn't achieve by using standard MVC approach. So maybe I am using the wrong approach here. So I was thinking about using contentparts for creating an order and displaying them and using the drivers and handlers for that. But before I go down that road and refactor everything I want to know if that is the right approach. A downside could be that once the module follows that route it can then not so easily be reused with customers that have other cms's capable of hosting an MVC3 module.
So when to use drivers, handlers and contentparts and when to use standard controllers and views.
You should use Drivers and Parts (with Handlers if needed) when you want to create functionality for content items. E.g. if you want to display a custom media with all products, you could create a Part (together with its Driver, etc.) to handle that. Read the docs on Parts.
If the functionality is not tied to content items the most possibly you want to use the standard MVC toolbox, it's fine. Look at the built-in modules how they do that. E.g. the Blog module uses controllers and views to show the admin UI, but has parts to enhance the functionality of for example the Blog content type.
To make things more complicated you can employ ad-hoc content items to build a page that you'd normally do with simple views, but that's an advanced topic :-).
I am designing a controller for reports. There will be about 10 different reports such as:
Courses Allocated
Courses Assigned
Logins
..etc..
Should I create a controller "reports" that would have urls such as:
/reports/courses_allocated?course=abc&start_date=2001-01-01&end_date=2011-01-01
/reports/courses_assigned?course=abc&start_date=2001-01-01&end_date=2011-01-01
There will also be ajax actions that will return data such as get_courses_by_category. (Should this ajax action have it own method, since it has to do with reports, or should this be part of the courses controller)
I am just looking for recommendations on how to design a report system which is mostly just complex sql queries that generate graphs in highcharts (Ajax loaded data) and tabular data.
Reporting is annoying, with that in mind you should spend as little time as possible on it. I recommend using searchlogic for make your models easier to query, it'll save you writing all the plumbing from your query string -> sql query.
Another thing that's worth thinking about is that your query roots will most likely be scopes, so if you were to have (for example):
/courses/allocated
That would (maybe) map to Course.allocated.
You could have a report controller, there's certainly nothing wrong with doing that, but I personally like to model my reporting around my existing controllers.
I have been thinking about this problem as well and concluded that for a situation where you have reporting associated with multiple models but following similar patterns a reports controller and perhaps generic code in lib makes sense. Reports have needs that are more common to themselves than they are to the models upon which they depend, for example: sort, search, filter, and then charting, exporting to files, permissions, etc.
My rationale is that when designing an application, you should think about it as an API, even if that's not how you are using it. Good APIs are consistent and predictable, and in effect this is what the controllers provide. Simple RESTful CRUD actions (generally speaking) belong in controllers associated with models.
Reporting is different, partly because it tends to cross models, and partly because there are different patterns and are likely to grow over time. For example, we have a report for our business partners that brings together payments, users accounts, and products in a single report; other reports provide a roll-up of metrics across multiple models. Reporting is its own thing.
I'm hoping this isn't too subjective, but I'm new to ASP.NET MVC and I'm trying to figure out how others may have solved similar problems.
Basically, I have two entities, Customers and Orders. A customer has many orders; an order belongs to exactly one customer. I'm making an Order Search feature that should allow a user to search for orders based on order or customer information. Pretty straightforward, I think.
I've read in other posts that the search controller should use GET, but I think it makes more sense to use POST because of the large number of search params.
I'm using Entity Framework to create my models, and that's in a separate class library project and namespace.
This article talks about using binding instead of Request.Form to get at the POST data. Would it make decent sense to make a class to hold all the search data that could be materialized by the magic model binding? Otherwise I'd just be poking through the FormCollection to pull out particular values, which might be fine. Where would you recommend making such a class?
This is only a partial answer, specifically to the "FormCollection vs Class" part. It's my opinion that you should always use a class for this unless you have a very good reason not to. You get compile-time checking here which is the #1 benefit. You also get Intellisense support which is helpful too. Lastly, you might get some performance benefits as there is potentially less casting/parsing done by your code.
For the GET vs POST question, I'm still struggling with that general question myself but I do have an opinion on your specific use of it. Currently, I'm leaning towards the following rules:
Use GET if the parameters identify an entity of some sort (i.e. ~/product/id/54 = a can of Coke)
Use POST if the parameters help generate a truly dynamic page where an ungodly number of such pages can exist (a search results screen being an example where there is nearly an infinite number of possibilities).
Now I may be way off with my GET vs POST opinion here, but I think there will be a lot of agreement on the class vs FormCollection opinion.
Use a class to encapsulate the search criteria. You can make this a property of your model and then use standard model binding. That way you can pass a single object to your search method, which is much neater and more extensible than having lots of parameters.