Ok this is more informative question than on a coding question. However this is a two part question.
When building the flavors for example an MP3 player.. you would have free and premium. I started designing a flavor app of an MP3 player to start learning Flavors and Build variants.
What i am trying to understand is when building the flavor is all of the design for the flavors built in Project then each flavor is specific. Premium features for Premium and free features for free. I understand that.
However what i am not understanding about the design is when i design my login with firebase how do i call the flavor thats appropriate. For testing purposes lets forget firebase. Here is an example:
MainActivity has two buttons. One will point to the free and the other paid. So if i press the free button do provide an intent that points to the flavor as this:
val i = Intent(......buildConfig.flavors.free)
Or would i place the package name in where the buildConfig would go. This is not actual code this is just an example.
Keep in mind i have never built a flavored app. So this is a learning point for me.
My original idea was have a free version as default with an in app purchase. You use the in app purchase and if the purchase is successful then the premium would take effect.. the only differences in the actual deaign would be those premium features are enabled.
So the first question would be: Is there really a difference between same design flavors versus in app purchases?
The second question is: when building a flavor app with the same design. Do you have to use flavors, example Free/paid, if the design never changes.
Like i said this is a learning process and all my apps on google play is just a flavorless app with adMob banner ad. So i an wanting to venture out to a more simple aspect than having two apps on google play one app for the free and another app for premium.
I think it would be easier to do flavors. However i have never done a flavored app and all the research i have done does not give clear instructions. They all stop after the gradel file implementation.
So any direction would help with is flavors a must or is it more headache to deal with in my case for learning purposes versus real world application.
I've searched for a while, but I can't find anything related on Google or here.
Me and some friends were debating starting a company, so I figure it might be good to do a quick pilot project to see how well we can work together. We have a designer who can do HTML, CSS and Flash, enjoys doing art, but doesn't like to do HTML and CSS... And 2 programmers that are willing to do anything.
My question is, from an experienced site builder's perspective, what steps do we do - in chronological order - to properly handle a website? Does the designer design the look and feel of the site, then the programmers fill in the gaps with functionality? Or do the programmers create a "mock-up" of the site with most of the functionality, then the designer spices it up? Or is it more of a back-and-forth process?
I just want to know how a professional normally handles it.
Update:
A recap taking some of the notes from each post.
Step 1: Define requirements. What will your site/application do?
Step 2: Use cases. Who will use the application, and what will they do with it? This doesn't have to be done with a bunch of crazy UML diagrams, just use whatever visual aids you think work best for you. Find a CMS vendor, or a search vendor, or both. While planning, maybe do some competitor analysis, and see how those in similar fields have done theirs.
Step 3: Visual proof-of-concept. This is done by your designer, NOT your programmers... Programmers are notoriously bad at UI. Use an image program like Photoshop, not an HTML editor. Leave it fluid and simple at first. Select the three-color theme for the site (two primaries and an accent.) Get a sense of how you want to lay things out, keeping in mind the chosen CMS and/or search functionality. Focus hard on usability, add pizzaz later. Turn the created concept into JPEG mock-ups, or create a staging site to allow the client to view the work. A staging site will allow for future releases to be tested prior to moving it to production.
Step 4: Once the site is conceptualized by your designers, have your HTML/CSS developer turn it into markup. He/she should shoot for XHTML compliance and test on as many major browsers as you can. Also a good time to set up versioning/bug tracking/management systems, to keep track of changes, bugs, and feedback.
Step 5: Have your programmers start turning your requirements into software. This can and should be done in parallel with Step 4- there's no reason they can't be coding up the major pieces and writing tests while the UI is designed and developed.
Step 6: Marry up the final UI design with the code. Test, Test, Test!!
Step 7: Display end result to client, and get client sign-off.
Step 8: Deploy the site to production.
Rinse, Repeat...
Step 1: Define requirements. What will your site/application do?
Step 2: Use cases. Who will use the application, and what will they do with it? This doesn't have to be done with a bunch of crazy UML diagrams, just use whatever visual aids you think work best for you.
Step 3: Visual proof-of-concept. This is done by your designer, NOT your programmers. Use an image program like Photoshop, not an HTML editor. Leave it fluid and simple at first. Select the three-color theme for the site (two primaries and an accent.) Get a sense of how you want to lay things out. Focus hard on usability, add pizzaz later.
Step 4: Once the site is conceptualized by your designers, have your HTML/CSS developer turn it into markup. He/she should shoot for XHTML compliance and test on as many major browsers as you can.
Step 5: Have your programmers start turning your requirements into software. This can and should be done in parallel with Step 4- there's no reason they can't be coding up the major pieces and writing tests while the UI is designed and developed.
Step 6: Marry up the final UI design with the code. Test, Test, Test!!
Rinse, Repeat...
There is no one universal way. Every shop does it differently. Hence, a warning: gross generalizations follow.
Web development typically consists of much shorter release cycles, because it's so simple to push out a release, compared to client-side software. Thus the more "agile" methods are more frequently used than the "waterfall" models encountered in developing client software.
Figure out what, exactly, you're building.
Take care of all the legal stuff (e.g. what business entity you'll be forming, how will each team member be compensated for their work, will there be health benefits, etc).
Mockups. I suggest having the designers do the mockups since programmers are notoriously bad at UI design.
Set up some sort of bug tracking / case management system so that you have a centralized place for all your feature requests and bug reports.
Start coding.
Once you have a simple version of your app, get some people to test it out to make sure you're on the right path.
???
Profit!
As a first step, I'd recommend doing a bit of up-front design using an approach such as paper prototyping, to lock down what it is you want your website to do, and roughly how you want it to look.
Next up, read up on the Agile approach to software development and see if you like the sound of what it suggests. It tends to work best with smaller, well-motivated teams.
Figure out the minimum amount of functionality you can create that you can deliver as a product so that you can get user feedback as soon as possibly. Then expect to iteratively add functionality to the product over time.
The Web Style Guide provides a pretty detailed overview of the process.
You should mix and match the lists provided here for your needs.
I just want to make sure you know one thing...
Customers are "stoopid" when it comes to web design.
You will have to claw, scrape, drag, gnash, rip, and extricate every requirement from their naive little souls. If you fail to do so? Guess who gets the blame?
The road you now look down is a hard one filled with competition, stress, and risk. It requires endurance, faith, patience, and the ability to eat ramen 5 of 7 days a week.
To add (or repeat) Dave Swersky's list.
Gather requirements from clients
Do some competitor analysis. Gather
screen shots of competitor sites.
Build a sitemap /wireframe - What is
the structure/content of the site?
Get designers to create JPG mockups.
They may use the screen shots for
"inspiration"
Get feedback from
clients based on JPEG's
Create HTML
mockups from JPEG's
Get feedback
from clients. Go back to step 4 if
necessary
Implement HTML using
technology of choice
Unit test the site
UAT and obtain sign off.
Deploy to live
client feedback is critical, they should be involved in every step to ensure a successful implementation.
Hope this helps
In addition to the steps outlined in other answers, I'd add this (to be added somewhere near the end of the "cycle"):
x. Once you have a more or less end to end solution, set up a staging site.
y. Get client sign off on staging site.
z. Deploy to production site.
Celebrate! But not too hard, there's almost always going to be a few iterations of changes, because users rarely know exactly what they really want the first time around.
So, when (not if), the client asks for changes, you can work on the changes and promote them to the staging site first! This is important because a) it gives clients a chance to preview changes before the whole world sees them b) if the integrity of the data on the production site is important, you can hopefully weed out any issues on the staging site before they impact production data.
Just to give something on the other side of the coin. Where I work, we have for the past couple of years, worked on a redesign of the company's website. Here are some highlights of the process:
Identify vendors for various functions that will be needed. In this case that meant finding a Content Management System vendor as well as a Search vendor.
Get a new design for the site that can be applied to what was selected in the first step.
Using system integrators and in-house developers, start to build some of the functionality for the site and take the flexible, customizable software in 1 and make it useful for the organization. Note that this is where a couple of years have been spent getting this working and some business decisions ironed out.
Release a preview site to verify functionality and fix bugs, add enhancements as needed.
Note that in your case you may not have the same budget but there are various CMS frameworks out there to select as well as how much integration do you want to have for the site? Does it have to talk to a half-dozen different systems? In the case I mentioned above there are CRM integrations, ESB integrations, search integrations, and translation integrations to give a few examples of where things had to be wired up correctly.
In response to the comment, be sure you and the client know what is meant by "simple" as if there is any e-commerce functionality, forums, or personalization these are examples where it can be important to know what is needed now and have an idea of what is needed down the road as there can likely be a ton of things that customers may want but you have to figure out some of the nitty-gritty details at points in the future. For example, some people may think that Google is simple, and from an end-user perspective it is though how many computers does Google have running how many different applications doing how much processing 24/7? Quite a bit, I'd imagine. Simple is good, but sometimes making something look simple can be incredibly hard to do.
I need to build an internal order entry and tracking system for a grocery store which requires many of the features of existing e-commerce systems, such as product catalog, customer_to_order relations/views, movement reporting, order statuses, etc. However, the first phase of the product is purely internal, so I don't need any online e-commerce features such as shipping addresses, postal rates or a payment gateway. I've also got a bunch of business specific stuff that may not apply to a lot of on-line stores: complex product/customer discount system, lots of attributes for the products, a producer order-tracking flow (customer has an order with us and we have an order with the producer), and so on.
So I'm stuck wondering if I would be better off customizing an existing product, or rolling my own with a good web framework (such as Python/web2py)? If it was a cut-and-dry online store, then the decision would be clear - but it's not. So I'm trying to find the most extensible/flexible FOSS e-commerce software for prototyping.
The main contenders I've been considering so far are: Drupal/Ubercart, Django/Satchmo and RoR/Spree. Ubercart is undergoing a complete re-write as Drupal Commerce, so that puts me off. The Spree project looks clean and I like the ideas - but I'm already writing a product/customer ETL in Jython and don't want to balance the two languages - both Python and Ruby are new to me.
I don't like Magento's enterprise/community edition model. And I've heard lots of complaints about osCommerce and it's variants.
Thanks in advance for your thoughts.
By the way, I think the gap between the feature-set I need and what I could get out-of-the-box from an existing e-commerce product is on the order of 30%.
if you need that much extra functionality I reckon roll your own so you aren't constrained later.
Or better yet fork the current very basic (and easy to understand) web2py estore:
http://code.google.com/p/web2py-estore/
http://web2py-estore.appspot.com/ (demo)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to land my first programming-related job, and I found a website for a company which is accepting resumes for an eCommerce development position.
This is the requirements they listed:
To be proficient in:
HTML (hand-coded)
CSS
PHP
Javascript
MySQL
Preferred skills:
PEARL
Linux
The fact that they (unless they're actually using the PEARL programming language) misspelled perl and have a fairly bland portfolio aside, I can do all of this--I mean, I need to touch up on my Javascript and learn a bit more MySQL--but I can do all this, and I'm sure I can pick up perl in no time. But I was wondering--what exactly does an eCommerce developer do? Is this like, building shopping carts? User login systems? Or does it just mean doing everything except design on corporate websites?
eCommerce has one big word that goes with it Security.
Do you feel confident writing secure code? Bearing in mind that your code will be handling the users credit card information.
Now, there is alot that goes into building an eCommerce solution from the ground up
Product Listings
Adding/Removing Items
Sort by size/shape/price/color/...
Search
Filtering results
Shopping cart (harder then it sounds)
Database or Session?
Adding/Removing Items
Checkout
Integration with payment API
Reporting
Inventory
Security
XSS
SQL Injections
I would suggest that ecommerce is so much more than a specific technology. ECom is more about how the database is built and the features that are required. There is a good book that I read 10 years (a long time) ago that goes into ecommerce with asp classic. But there are many new ones using newer technologies here.
The big key is how you structure your data, products, options, orders, order details, credit card/user data, etc. Also, the various ways of processing transactions. How to handle order pipelines. When to offer navigations away from the current page and when not too. How to make product recommendations. Dealing with tax API's and shipping API's. You might consider downloading DashCommerce (a .net application) or something similar that fits your preferred technologies to see how they have set things up. Install something. Get it set up to feel the pains for data management. ...also to feel the pains of navigating a shopping cart (adding products to the cart, updating the cart, checking out, setting up an account or having an anonymous checkouts).
Being an commerce developer generally means knowing how to work with Verisign (now paypal) or similar payment processing. How to intercept fraudulent transactions and deal with them appropriately. How to work in a high transaction environment (caching, tierd architectures, queues, web services). Cross linking products based on user history/profiling to maximize transactions (think candy at the check out stand of a grocery store). Knowing how to work in a secure manner with sensitive data which generally means encryption techniques, setting up DMZ's, working with proxies, etc. Take a look at using some form of a rule engine for order pipelines so that your business rules are separate from your application logic. Understand coupons schemes, discounts, etc. Frequently ad campaigns are heavily used for generating side income.
Ecommerce can be a big topic!
It all depends on what you are working with.
I have been working as an e-commerce developer for half a year now.
I have used the Magento platform for all of my work.
Since standard Magento is already very secure you won't have to do much security code.
Mostly you change the layout and the design of the standard Magento shop and add any new features the client wants.
Most of these can be achieved by downloading custom modules built by other developers or you can build them yourself. Building a Magento module the right way is quite difficult for someone who is kind of new to programming or new to Magento.
I know this topic is rather old, but i thought someone might still benefit from this answer.
I've got a contract to build an e-commerce site. It doesn't make much sense to build it from scratch (rebuild the wheel).
There's plenty of Open Source platforms such as osCommerce or Magnetocommerce. There's also some commercial platforms (I don't mind a small outlay if it's worth id)
Does anyone have any experience building upon an ecommerce platform like these ?
I've used osCommerce and its ok. But CreLoaded is much, much better. CreLoaded is based on osCommerce, but with all the best of the best add-ins pre-installed.
What can make osCommerce and CreLoaded really stand out as a top of the range products are two things:
Templates
Optional add-ins.
Templates
There are 256 templates for CreLoaded at template monster. Costing only $140 which is cheap, considering the quality and quantity of the graphics.
Optional add-ins.
Add-ins are hard to implement as you have to patch the code manually.
However, the saving grace is that there is CreLoaded. This is oscommerce with all the best Add-ins pre-installed.
Erol
I also purchased Erol v4 for my blank media store. The site looks ok, but its just dreadful. Written in Microsoft Access. Total rubbish. BTW, i've since closed the shop so please don't purchase anything!
I looked at a LOT of commerce packages! And CreLoaded is the one to go for in my own opinion.
I would go for WooCommerce on Wordpress. You get great support with a lot of free functionalities. Also a lot of wordpress themes are Woocommerce ready so you have a wide ocean of options for themes and plugins
You might be interested by answers to What’s the best free and opensource PHP ecommerce solution? (and why?), at least it provide answers for one platform.