all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Purple
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
On a Zoom session with Russell. We were talking about visual displays out in ecommerce land. We talked about options for selling parent items and having it check to see if that item was already in the cart. If yes, just update the quantity and price and taxes. If it is a different item, just add it normally. This makes the cart line items look smaller. The quantity is increased but the line items are smaller. This will have problems when we get out to the sub inventory level. As a possible work around: - We could keep all of the data and just display a summary (customer friendly view) or we could add in a sub array and hold more info behind the scenes. When we get to subs and mini conversion, we do need that extra level of detail. By way of a note, the summary needs to check for the part id's, the units of measure, and price. If it is all the same, we could technically show it in the summary view. If anything else is different, we need a new visual line. Another project that Russell and Alan are working on is called real reviews. This is tied into elements of time and sub comments. Russell is looking to add an additional field to the sub comments. He wants to connect them out to customers (customer id's) and a possible value or rating field. Think of a review or blog post... It might be nice if we could rate things (5 stars, 9 out of 10, good, poor, excellent... etc.). We may also want to put a show/hide on the web setting for sub comments. The deeper we go, the more we are seeing the need for sub notifications, sub communications, sub updates, sub sign-offs, and even deeper push type technology. Pretty cool to see how multiple different things end up needing the same type sub functions. On related items... Russell is thinking that he will add a new ecommerce option for parts that will allow for list of id numbers. This will be similar to the long description. We are looking at additional items (virtual add-on's or packages) as well as the related items. For example: The additional items are similar to a build and sell recipe (a pre-set group or kit). The related items are like cousins, aunts, and uncle type items... One set is really tight (part of the main package) and the other ones are just similar and/or good companion type items. As a future note, we would love to get the build and sell recipes out into ecommerce land. As a fun side note... Russell was using video recording of the project scope as part of the documentation and planning for the project. That way we doesn't have to go over it again and again for the different parties who will be playing things. Do it once and then use it over and over again. Good old one-to-many relationships. Good stuff. On Russell's project called "tags" we would like to add the option to help the users be able to call it whatever they want (think naming and settings). We are leaning toward parent attributes and then attribute values. This could be called tags and tag values or whatever. We are seeing this as a way to expand the parent inventory table. It helps with searches, SEO (search engine optimization), filters, ecommerce stuff, drill-down criteria, etc. We could call it parent attribute groupings, parent attribute values, flags, tags, types, categories, etc. Think super generic or as a generic tool. As a side note, we may need some web and ecommerce type settings to go along with these values. Just because we have it and it has a value, do we really want to show/hide it outside in ecommerce. We may need some settings dealing with where it shows up (internally and externally) as well as do it have a color, a sort, an icon, etc. What about parent attribute data types? This is more of a question than anything else. In sub attributes, we allow for text, data/times, and numeric. What about similar things for parent attributes? What about other data types such as yes/no (1's and 0's or Boolean values), long text or html compatible fields, etc. That could be really cool. Russell was talking about how the parent attributes will play. Basically, they are tied to items and items are tied to part categories and sub part categories. Basically, he doesn't want to show everything... He wants to look under a certain main part category or sub part category and then pull back options from there. Basically, instead of just showing all parent attributes, we want the ecommerce pages to show the correct (lightly filtered) view to the users. That keeps everything relevant to what is being shown. There may be times that we need to show more options but we can figure that out. |